Mailman 3 Branches post 3.0 - yt-dev

newer
Status of sunrise exporter, radmc,...

Branches post 3.0

Matthew Turk

23 Jul 2014 23 Jul '14

4:18 a.m.

Hi everyone, Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage. * Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was: * stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet The alternate idea was: * stable => 3.0 * yt => 3.0 * yt-3.0 => closed I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0. -Matt

Show replies by date

Chris Malone

23 Jul 23 Jul

7:58 a.m.

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API. On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...

Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

John ZuHone

8:13 a.m.

I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore. I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0. There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me. My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x. So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes. Sorry, didn't intend to write a book. On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

...

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote: Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

8:24 a.m.

This is a compelling argument. What if we had: stable => which we could call call "legacy" on the front page yt => which is mainline yt-3.0, called "modern" on the front page? On Wed, Jul 23, 2014 at 10:13 AM, John ZuHone wrote:

...

I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore.

I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0.

There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me.

My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x.

So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes.

Sorry, didn't intend to write a book.

On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Douglas Harvey Rudd

8:27 a.m.

I was trying to come up with a similar name for an "old stable" and legacy is better than anything I came up with. I think you should keep the name stable for the current version, however. Douglas Rudd Scientific Computing Consultant Research Computing Center drudd@uchicago.edu On Jul 23, 2014, at 10:24 AM, Matthew Turk wrote:

...

This is a compelling argument.

What if we had:

stable => which we could call call "legacy" on the front page yt => which is mainline yt-3.0, called "modern" on the front page?

On Wed, Jul 23, 2014 at 10:13 AM, John ZuHone wrote:

...
I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore.

I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0.

There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me.

My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x.

So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes.

Sorry, didn't intend to write a book.

On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Michael Zingale

8:24 a.m.

I think I agree with John. When people say "yt", we want that to be synonymous with 3.0 -- that's where the action is happening. On Wed, Jul 23, 2014 at 11:13 AM, John ZuHone wrote:

...

I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore.

I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0.

There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me.

My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x.

So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes.

Sorry, didn't intend to write a book.

On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

Chris Malone

8:28 a.m.

My main impetus for going with option 1 was so that there was a longer delay for folks using 2.x. I would be completely onboard with making 3.0 the 'modern' version, as long as users still have access to a 2.x for awhile. On Wed, Jul 23, 2014 at 9:24 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:

...

I think I agree with John. When people say "yt", we want that to be synonymous with 3.0 -- that's where the action is happening.

On Wed, Jul 23, 2014 at 11:13 AM, John ZuHone wrote:

...
I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore.

I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0.

There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me.

My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x.

So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes.

Sorry, didn't intend to write a book.

On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Michael Zingale Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Cameron Hummels

9:34 a.m.

I like 2.x -> legacy, 3.0 -> stable, 3.x (dev) -> dev. People are going to go to "stable" by default, and if we don't have a "stable", I think they'll be a bit confused and not know whether to go with legacy or modern. On Wed, Jul 23, 2014 at 8:28 AM, Chris Malone wrote:

...

My main impetus for going with option 1 was so that there was a longer delay for folks using 2.x. I would be completely onboard with making 3.0 the 'modern' version, as long as users still have access to a 2.x for awhile.

On Wed, Jul 23, 2014 at 9:24 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:

...
I think I agree with John. When people say "yt", we want that to be synonymous with 3.0 -- that's where the action is happening.

On Wed, Jul 23, 2014 at 11:13 AM, John ZuHone wrote:

...
I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore.

I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0.

There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me.

My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x.

So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes.

Sorry, didn't intend to write a book.

On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Michael Zingale Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

Nathan Goldbaum

10:09 a.m.

On Wed, Jul 23, 2014 at 8:28 AM, Chris Malone wrote:

...

My main impetus for going with option 1 was so that there was a longer delay for folks using 2.x. I would be completely onboard with making 3.0 the 'modern' version, as long as users still have access to a 2.x for awhile.

The code will still be there of course. I'd personally prefer to keep 2.x on a separate named branch, making switching back straightforward. That said, I think the 3.0 release should live in the stable branch. As an anecdote, I'd say about 50% of the advice traffic I get on the IRC channel is from users who are on 3.0 already.

...

On Wed, Jul 23, 2014 at 9:24 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:

...
I think I agree with John. When people say "yt", we want that to be synonymous with 3.0 -- that's where the action is happening.

On Wed, Jul 23, 2014 at 11:13 AM, John ZuHone wrote:

...
I think that continuing to denote 2.x as "stable" leaves us in a situation akin to Python 2.x vs. 3.x (though not quite as extreme of course). I think that doing so will have a large effect on perception of what people feel is "safe" to use for their analysis. We do think that 3.0 is indeed "safe" for this, right? If not, then we ought to state explicitly that 3.0 is still in "beta" or at the very least is a "release candidate". I don't think any of us would say that 3.0 is "beta" anymore.

I'm just worried that it will slow migration to 3.0, at a time when most of us have already switched over to thinking in terms of 3.0's syntax and API. We'll certainly continue to support 2.x users, but I thought we wanted them all to migrate (unless they need something that isn't ported yet). Plus, it will certainly be confusing if we mark 2.x as "stable" but nevertheless have all defaults (documentation links, etc.) point to 3.0.

There are certainly a lot of things about 3.0 that are still maybe close to the bleeding edge, but we've all done a lot of hard work in making sure that the test suite still passes, which is more than you can say for a lot of codes out there (though this situation is improving, thankfully). So 3.0 is pretty "stable", if you ask me.

My last experience with something like this was the release of FLASH 3.0, which was a pretty substantial break from previous versions. In that case, we made no hesitations that 3.0 was the new "stable" version and strongly encouraged folks to migrate from 2.x.

So +1 on option 2, or something like it, with a 2.x branch remaining for bugfixes.

Sorry, didn't intend to write a book.

On Jul 23, 2014, at 10:58 AM, Chris Malone wrote:

+1 for option 1, but stress on the homepage all the cool things 3.0 can bring to the table so that users are willing to break their scripts when moving to the new API.

On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.) But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Michael Zingale Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Nathan Goldbaum

10:07 a.m.

On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk wrote:

...

Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.)

Why is that?

...

But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

...

The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

...

I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

10:26 a.m.

On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote:

...

On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.)

Why is that?

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

...

...
But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

...
The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

...
I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Nathan Goldbaum

10:32 a.m.

On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk wrote:

...

On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk

wrote:

...
...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.)

Why is that?

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

...

...
...
But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

...
The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

...
I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Britton Smith

10:54 a.m.

Hi everyone, I'm late to the discussion, but here's my opinion: 1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release. Further development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible. I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible. The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the thing you want people starting on. Once yt-3.0 is released, that should be yt-3.0. Britton On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum wrote:

...

On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk wrote:

...
On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk

wrote:

...
...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.)

Why is that?

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

...
...
...
But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

...
The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

...
I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Sam Skillman

11:01 a.m.

Also late to the discussion, but have been following along. I think I like Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable. Sam On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith wrote:

...

Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release. Further development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the thing you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk wrote:

...
On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk

wrote:

...
...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.)

Why is that?

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

...
...
...
But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

...
The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

...
I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

2:57 p.m.

Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it. So, when we release, how about this? yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip. How's that sound? On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote:

...

Also late to the discussion, but have been following along. I think I like Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release. Further development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the thing you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk wrote:

...
On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk wrote:

...
Hi everyone,

Yesterday during the doc sprint, the question of what to do about branches post-3.0 came up. Currently there are three branches, which correspond to different names on the front page of the yt homepage.

* Stable => The branch into which bug fixes are merged, but not a lot of active development occurs. * yt => The 2.x development branch, which has slowed almost to a halt * yt-3.0 => The 3.0 development branch

It seems there is broad consensus that after the release, the yt-3.0 branch would be merged into the yt branch. (I would like to hold off on "closing" the yt-3.0 branch for a while, however.)

Why is that?

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

...
...
...
But, what is then to be done about the "stable" branch? My thought was:

* stable => will be on 2.x for at least one release, until 3.1 * yt => 3.0 * yt-3.0 => we try to migrate development onto the yt branch, which is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

...
The alternate idea was:

* stable => 3.0 * yt => 3.0 * yt-3.0 => closed

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

...
I think we need a longer migration time for 2.x, though. I will update YTEP-0008 with whatever we come up with, but is there a strong opinion for either of these options? Option 1: stable stays 2.x for now, Option 2, stable becomes 3.0.

-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Nathan Goldbaum

2:59 p.m.

On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote:

...

Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1 http://i.imgur.com/vwMin.gif

...

...
Also late to the discussion, but have been following along. I think I

...
Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release.

Further

...
development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x

...
...
some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the

On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote: like live thing

...
...
you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum
...
wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk wrote:

...
On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk <

matthewturk@gmail.com>

...
...
...
wrote: > > Hi everyone, > > Yesterday during the doc sprint, the question of what to do about > branches post-3.0 came up. Currently there are three branches, which > correspond to different names on the front page of the yt homepage. > > * Stable => The branch into which bug fixes are merged, but not a > lot > of active development occurs. > * yt => The 2.x development branch, which has slowed almost to a > halt > * yt-3.0 => The 3.0 development branch > > It seems there is broad consensus that after the release, the yt-3.0 > branch would be merged into the yt branch. (I would like to hold off > on "closing" the yt-3.0 branch for a while, however.)

Why is that?

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

...
...
> > But, what is > then to be done about the "stable" branch? My thought was: > > * stable => will be on 2.x for at least one release, until 3.1 > * yt => 3.0 > * yt-3.0 => we try to migrate development onto the yt branch,

which

...
...
> is 3.0, but don't force yet

I'd be -1 on having bugfixes for 3.0 on two branches.

> > > The alternate idea was: > > * stable => 3.0 > * yt => 3.0 > * yt-3.0 => closed >

I'd prefer this, possibly with another named branch named "legacy" that contains 2.x.

> > I think we need a longer migration time for 2.x, though. I will > update YTEP-0008 with whatever we come up with, but is there a strong > opinion for either of these options? Option 1: stable stays 2.x for > now, Option 2, stable becomes 3.0. > > -Matt > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Britton Smith

2:59 p.m.

+1 On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum wrote:

...

On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote:

...
Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1

http://i.imgur.com/vwMin.gif

...
...
Also late to the discussion, but have been following along. I think I

...
Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith
wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release.

Further

...
development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x

...
...
some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the

On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote: like live thing

...
...
you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum < nathan12343@gmail.com> wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk
...
...
wrote:

...
On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum wrote: > > > > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk <

matthewturk@gmail.com>

...
> wrote: >> >> Hi everyone, >> >> Yesterday during the doc sprint, the question of what to do about >> branches post-3.0 came up. Currently there are three branches, which >> correspond to different names on the front page of the yt homepage. >> >> * Stable => The branch into which bug fixes are merged, but not a >> lot >> of active development occurs. >> * yt => The 2.x development branch, which has slowed almost to a >> halt >> * yt-3.0 => The 3.0 development branch >> >> It seems there is broad consensus that after the release, the yt-3.0 >> branch would be merged into the yt branch. (I would like to hold off >> on "closing" the yt-3.0 branch for a while, however.) > > > Why is that? >

Because until we get to the point that every developer has issued PRs for all of their yt-3.0 development, we're going to have multiple instances of "closing yt-3.0". Because it's decentralized, we can't force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

...
>> >> But, what is >> then to be done about the "stable" branch? My thought was: >> >> * stable => will be on 2.x for at least one release, until 3.1 >> * yt => 3.0 >> * yt-3.0 => we try to migrate development onto the yt branch,

which

...
>> is 3.0, but don't force yet > > > I'd be -1 on having bugfixes for 3.0 on two branches. > >> >> >> The alternate idea was: >> >> * stable => 3.0 >> * yt => 3.0 >> * yt-3.0 => closed >> > > I'd prefer this, possibly with another named branch named "legacy" > that > contains 2.x. > >> >> I think we need a longer migration time for 2.x, though. I will >> update YTEP-0008 with whatever we come up with, but is there a strong >> opinion for either of these options? Option 1: stable stays 2.x for >> now, Option 2, stable becomes 3.0. >> >> -Matt >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Cameron Hummels

3:02 p.m.

+1 so `stable` will be locked at a given bookmark/changeset, whereas `yt` will from then on be the development branch? On Wed, Jul 23, 2014 at 2:59 PM, Britton Smith wrote:

...

+1

On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote:

...
Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1

http://i.imgur.com/vwMin.gif

...
...
Also late to the discussion, but have been following along. I think I

...
Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith < brittonsmith@gmail.com> wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release.

Further

...
development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or

On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote: like the thing

...
...
you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum < nathan12343@gmail.com> wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk <

matthewturk@gmail.com>

...
wrote: > > On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum > wrote: > > > > > > > > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk < matthewturk@gmail.com> > > wrote: > >> > >> Hi everyone, > >> > >> Yesterday during the doc sprint, the question of what to do about > >> branches post-3.0 came up. Currently there are three branches, which > >> correspond to different names on the front page of the yt homepage. > >> > >> * Stable => The branch into which bug fixes are merged, but not a > >> lot > >> of active development occurs. > >> * yt => The 2.x development branch, which has slowed almost to a > >> halt > >> * yt-3.0 => The 3.0 development branch > >> > >> It seems there is broad consensus that after the release, the yt-3.0 > >> branch would be merged into the yt branch. (I would like to hold off > >> on "closing" the yt-3.0 branch for a while, however.) > > > > > > Why is that? > > > > Because until we get to the point that every developer has issued PRs > for all of their yt-3.0 development, we're going to have multiple > instances of "closing yt-3.0". Because it's decentralized, we can't > force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

> > > >> > >> But, what is > >> then to be done about the "stable" branch? My thought was: > >> > >> * stable => will be on 2.x for at least one release, until 3.1 > >> * yt => 3.0 > >> * yt-3.0 => we try to migrate development onto the yt branch, which > >> is 3.0, but don't force yet > > > > > > I'd be -1 on having bugfixes for 3.0 on two branches. > > > >> > >> > >> The alternate idea was: > >> > >> * stable => 3.0 > >> * yt => 3.0 > >> * yt-3.0 => closed > >> > > > > I'd prefer this, possibly with another named branch named "legacy" > > that > > contains 2.x. > > > >> > >> I think we need a longer migration time for 2.x, though. I will > >> update YTEP-0008 with whatever we come up with, but is there a strong > >> opinion for either of these options? Option 1: stable stays 2.x for > >> now, Option 2, stable becomes 3.0. > >> > >> -Matt > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

Matthew Turk

3:03 p.m.

On Wed, Jul 23, 2014 at 5:02 PM, Cameron Hummels wrote:

...

+1

so `stable` will be locked at a given bookmark/changeset, whereas `yt` will from then on be the development branch?

Sort of. Stable is a named branch, so we'll merge into it periodically.

...

On Wed, Jul 23, 2014 at 2:59 PM, Britton Smith wrote:

...
+1

On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote:

...
Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1

http://i.imgur.com/vwMin.gif

...
On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote:

...
Also late to the discussion, but have been following along. I think I like Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release. Further development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the thing you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum wrote: > > > > On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk > > wrote: >> >> On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum >> wrote: >> > >> > >> > >> > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk >> > >> > wrote: >> >> >> >> Hi everyone, >> >> >> >> Yesterday during the doc sprint, the question of what to do >> >> about >> >> branches post-3.0 came up. Currently there are three branches, >> >> which >> >> correspond to different names on the front page of the yt >> >> homepage. >> >> >> >> * Stable => The branch into which bug fixes are merged, but not >> >> a >> >> lot >> >> of active development occurs. >> >> * yt => The 2.x development branch, which has slowed almost to >> >> a >> >> halt >> >> * yt-3.0 => The 3.0 development branch >> >> >> >> It seems there is broad consensus that after the release, the >> >> yt-3.0 >> >> branch would be merged into the yt branch. (I would like to >> >> hold off >> >> on "closing" the yt-3.0 branch for a while, however.) >> > >> > >> > Why is that? >> > >> >> Because until we get to the point that every developer has issued >> PRs >> for all of their yt-3.0 development, we're going to have multiple >> instances of "closing yt-3.0". Because it's decentralized, we >> can't >> force all, everywhere, to be closed. > > > Ah, of course that makes sense. I guess we'll need to have two open > development branches and merge from the yt-3.0 branch into the yt > branch > regularly. > >> >> >> >> >> >> But, what is >> >> then to be done about the "stable" branch? My thought was: >> >> >> >> * stable => will be on 2.x for at least one release, until 3.1 >> >> * yt => 3.0 >> >> * yt-3.0 => we try to migrate development onto the yt branch, >> >> which >> >> is 3.0, but don't force yet >> > >> > >> > I'd be -1 on having bugfixes for 3.0 on two branches. >> > >> >> >> >> >> >> The alternate idea was: >> >> >> >> * stable => 3.0 >> >> * yt => 3.0 >> >> * yt-3.0 => closed >> >> >> > >> > I'd prefer this, possibly with another named branch named >> > "legacy" >> > that >> > contains 2.x. >> > >> >> >> >> I think we need a longer migration time for 2.x, though. I will >> >> update YTEP-0008 with whatever we come up with, but is there a >> >> strong >> >> opinion for either of these options? Option 1: stable stays 2.x >> >> for >> >> now, Option 2, stable becomes 3.0. >> >> >> >> -Matt >> >> _______________________________________________ >> >> yt-dev mailing list >> >> yt-dev@lists.spacepope.org >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> > >> > >> > _______________________________________________ >> > yt-dev mailing list >> > yt-dev@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

John ZuHone

3:09 p.m.

+1 John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com

...

On Jul 23, 2014, at 5:59 PM, Britton Smith wrote:

+1

...
On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote: Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1

http://i.imgur.com/vwMin.gif

...
On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote:

...
Also late to the discussion, but have been following along. I think I like Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release. Further development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the thing you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk wrote: > > On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum > wrote: > > > > > > > > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk > > wrote: > >> > >> Hi everyone, > >> > >> Yesterday during the doc sprint, the question of what to do about > >> branches post-3.0 came up. Currently there are three branches, which > >> correspond to different names on the front page of the yt homepage. > >> > >> * Stable => The branch into which bug fixes are merged, but not a > >> lot > >> of active development occurs. > >> * yt => The 2.x development branch, which has slowed almost to a > >> halt > >> * yt-3.0 => The 3.0 development branch > >> > >> It seems there is broad consensus that after the release, the yt-3.0 > >> branch would be merged into the yt branch. (I would like to hold off > >> on "closing" the yt-3.0 branch for a while, however.) > > > > > > Why is that? > > > > Because until we get to the point that every developer has issued PRs > for all of their yt-3.0 development, we're going to have multiple > instances of "closing yt-3.0". Because it's decentralized, we can't > force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

> > > >> > >> But, what is > >> then to be done about the "stable" branch? My thought was: > >> > >> * stable => will be on 2.x for at least one release, until 3.1 > >> * yt => 3.0 > >> * yt-3.0 => we try to migrate development onto the yt branch, which > >> is 3.0, but don't force yet > > > > > > I'd be -1 on having bugfixes for 3.0 on two branches. > > > >> > >> > >> The alternate idea was: > >> > >> * stable => 3.0 > >> * yt => 3.0 > >> * yt-3.0 => closed > >> > > > > I'd prefer this, possibly with another named branch named "legacy" > > that > > contains 2.x. > > > >> > >> I think we need a longer migration time for 2.x, though. I will > >> update YTEP-0008 with whatever we come up with, but is there a strong > >> opinion for either of these options? Option 1: stable stays 2.x for > >> now, Option 2, stable becomes 3.0. > >> > >> -Matt > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Sam Skillman

3:14 p.m.

+1 On Wed, Jul 23, 2014 at 3:09 PM, John ZuHone wrote:

...

+1

John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com

On Jul 23, 2014, at 5:59 PM, Britton Smith wrote:

+1

On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote:

...
Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1

http://i.imgur.com/vwMin.gif

...
...
Also late to the discussion, but have been following along. I think I

...
Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith < brittonsmith@gmail.com> wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release.

Further

...
development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or

On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote: like the thing

...
...
you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum < nathan12343@gmail.com> wrote:

...
On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk <

matthewturk@gmail.com>

...
wrote: > > On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum > wrote: > > > > > > > > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk < matthewturk@gmail.com> > > wrote: > >> > >> Hi everyone, > >> > >> Yesterday during the doc sprint, the question of what to do about > >> branches post-3.0 came up. Currently there are three branches, which > >> correspond to different names on the front page of the yt homepage. > >> > >> * Stable => The branch into which bug fixes are merged, but not a > >> lot > >> of active development occurs. > >> * yt => The 2.x development branch, which has slowed almost to a > >> halt > >> * yt-3.0 => The 3.0 development branch > >> > >> It seems there is broad consensus that after the release, the yt-3.0 > >> branch would be merged into the yt branch. (I would like to hold off > >> on "closing" the yt-3.0 branch for a while, however.) > > > > > > Why is that? > > > > Because until we get to the point that every developer has issued PRs > for all of their yt-3.0 development, we're going to have multiple > instances of "closing yt-3.0". Because it's decentralized, we can't > force all, everywhere, to be closed.

Ah, of course that makes sense. I guess we'll need to have two open development branches and merge from the yt-3.0 branch into the yt branch regularly.

> > > >> > >> But, what is > >> then to be done about the "stable" branch? My thought was: > >> > >> * stable => will be on 2.x for at least one release, until 3.1 > >> * yt => 3.0 > >> * yt-3.0 => we try to migrate development onto the yt branch, which > >> is 3.0, but don't force yet > > > > > > I'd be -1 on having bugfixes for 3.0 on two branches. > > > >> > >> > >> The alternate idea was: > >> > >> * stable => 3.0 > >> * yt => 3.0 > >> * yt-3.0 => closed > >> > > > > I'd prefer this, possibly with another named branch named "legacy" > > that > > contains 2.x. > > > >> > >> I think we need a longer migration time for 2.x, though. I will > >> update YTEP-0008 with whatever we come up with, but is there a strong > >> opinion for either of these options? Option 1: stable stays 2.x for > >> now, Option 2, stable becomes 3.0. > >> > >> -Matt > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

3:15 p.m.

Great. Once in place I will send an email to yt-users describing this. (It will be after the yt-3.0 announcement email.) On Wed, Jul 23, 2014 at 5:14 PM, Sam Skillman wrote:

...

+1

On Wed, Jul 23, 2014 at 3:09 PM, John ZuHone wrote:

...
+1

John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com

On Jul 23, 2014, at 5:59 PM, Britton Smith wrote:

+1

On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum wrote:

...
On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk wrote:

...
Alright, so it seems like there's a bit of a broad consensus on making "stable" mean 3.0. I think my reluctance may just be related to anxiety about breakage. But, let's push through it.

So, when we release, how about this?

yt-3.0 => deprecated, not closed. Eventually, we will close. yt => this will be merged *into* from yt-3.0 stable => this will be merged *into* from yt, post-3.0 merge (i.e., it will be 3.0) yt-2.x => this will be a new branch that starts at the current "stable" tip.

How's that sound?

+1

http://i.imgur.com/vwMin.gif

...
On Wed, Jul 23, 2014 at 1:01 PM, Sam Skillman wrote:

...
Also late to the discussion, but have been following along. I think I like Britton's suggestion here. Named yt-2 branch will allow it exist in history and if for some reason additional development is done on it, there is an obvious path forward. I also agree that when yt-3.0 is released it should be merged into yt and stable.

Sam

On Wed, Jul 23, 2014 at 10:54 AM, Britton Smith wrote:

...
Hi everyone,

I'm late to the discussion, but here's my opinion:

1. yt-x.2 should become a named branch (maybe just "yt-2"). 2. yt-3.0 goes into "yt" and "stable" at the time of the release. Further development happens in "yt" just as it used to. 3. yt-3.0 the branch closes as soon as is feasible.

I don't like names like "legacy", "modern", etc that do not really describe what it is. yt-2.x may get one or more final point releases and/or bugfixes that will need a home and I think it's worthwhile that yt-2.x live some place visible.

The "stable" branch should always stand for "if you don't know what you want, you want this" which to me is the latest trusted release, or the thing you want people starting on. Once yt-3.0 is released, that should be yt-3.0.

Britton

On Wed, Jul 23, 2014 at 6:32 PM, Nathan Goldbaum wrote: > > > > On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk > > wrote: >> >> On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum >> wrote: >> > >> > >> > >> > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk >> > >> > wrote: >> >> >> >> Hi everyone, >> >> >> >> Yesterday during the doc sprint, the question of what to do >> >> about >> >> branches post-3.0 came up. Currently there are three branches, >> >> which >> >> correspond to different names on the front page of the yt >> >> homepage. >> >> >> >> * Stable => The branch into which bug fixes are merged, but not >> >> a >> >> lot >> >> of active development occurs. >> >> * yt => The 2.x development branch, which has slowed almost to >> >> a >> >> halt >> >> * yt-3.0 => The 3.0 development branch >> >> >> >> It seems there is broad consensus that after the release, the >> >> yt-3.0 >> >> branch would be merged into the yt branch. (I would like to >> >> hold off >> >> on "closing" the yt-3.0 branch for a while, however.) >> > >> > >> > Why is that? >> > >> >> Because until we get to the point that every developer has issued >> PRs >> for all of their yt-3.0 development, we're going to have multiple >> instances of "closing yt-3.0". Because it's decentralized, we >> can't >> force all, everywhere, to be closed. > > > Ah, of course that makes sense. I guess we'll need to have two open > development branches and merge from the yt-3.0 branch into the yt > branch > regularly. > >> >> >> >> >> >> But, what is >> >> then to be done about the "stable" branch? My thought was: >> >> >> >> * stable => will be on 2.x for at least one release, until 3.1 >> >> * yt => 3.0 >> >> * yt-3.0 => we try to migrate development onto the yt branch, >> >> which >> >> is 3.0, but don't force yet >> > >> > >> > I'd be -1 on having bugfixes for 3.0 on two branches. >> > >> >> >> >> >> >> The alternate idea was: >> >> >> >> * stable => 3.0 >> >> * yt => 3.0 >> >> * yt-3.0 => closed >> >> >> > >> > I'd prefer this, possibly with another named branch named >> > "legacy" >> > that >> > contains 2.x. >> > >> >> >> >> I think we need a longer migration time for 2.x, though. I will >> >> update YTEP-0008 with whatever we come up with, but is there a >> >> strong >> >> opinion for either of these options? Option 1: stable stays 2.x >> >> for >> >> now, Option 2, stable becomes 3.0. >> >> >> >> -Matt >> >> _______________________________________________ >> >> yt-dev mailing list >> >> yt-dev@lists.spacepope.org >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> > >> > >> > _______________________________________________ >> > yt-dev mailing list >> > yt-dev@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

3562

Age (days ago)

3562

Last active (days ago)

List overview

Download

21 comments

9 participants

participants (9)

Britton Smith
Cameron Hummels
Chris Malone
Douglas Harvey Rudd
John ZuHone
Matthew Turk
Michael Zingale
Nathan Goldbaum
Sam Skillman

Branches post 3.0

Douglas Harvey Rudd

tags

participants (9)