[yt-dev] Branches post 3.0

Wed Jul 23 15:09:27 PDT 2014

+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 at nasa.gov
jzuhone at gmail.com

> On Jul 23, 2014, at 5:59 PM, Britton Smith <brittonsmith at gmail.com> wrote:
> 
> +1
> 
> 
>> On Wed, Jul 23, 2014 at 10:59 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
>> 
>> 
>> 
>>> On Wed, Jul 23, 2014 at 2:57 PM, Matthew Turk <matthewturk at gmail.com> 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 <samskillman at gmail.com> 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 <brittonsmith at 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 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 at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Wed, Jul 23, 2014 at 10:26 AM, Matthew Turk <matthewturk at gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> On Wed, Jul 23, 2014 at 12:07 PM, Nathan Goldbaum
>>> >>>> <nathan12343 at gmail.com> wrote:
>>> >>>> >
>>> >>>> >
>>> >>>> >
>>> >>>> > On Wed, Jul 23, 2014 at 4:18 AM, Matthew Turk <matthewturk at 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 at lists.spacepope.org
>>> >>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>> >
>>> >>>> >
>>> >>>> >
>>> >>>> > _______________________________________________
>>> >>>> > yt-dev mailing list
>>> >>>> > yt-dev at lists.spacepope.org
>>> >>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>> >
>>> >>>> _______________________________________________
>>> >>>> yt-dev mailing list
>>> >>>> yt-dev at lists.spacepope.org
>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> yt-dev mailing list
>>> >>> yt-dev at lists.spacepope.org
>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> yt-dev mailing list
>>> >> yt-dev at lists.spacepope.org
>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > yt-dev mailing list
>>> > yt-dev at lists.spacepope.org
>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> 
>> 
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140723/65206720/attachment.html>