[yt-dev] Proposed: release dates for 2.6, 2.6.x, and 3.0

[Matthew Turk]

On Mon, Oct 7, 2013 at 6:01 AM, Britton Smith <brittonsmith at gmail.com> wrote:
> I was under the impression that yt-3.0 development was already being done in
> the yt_analysis/yt repository.  There is definitely a yt-3.0 branch in
> there.  Is it not being used?  If not, I don't think a strong case can be
> made for people trying it until then.

It is, but it's only updated when a new "release" happens -- so most
high-cadence development happens in the other repo.

>
> On the branch naming question, if we were to merge yt-3.0 development into
> the yt branch, what would happen to the yt-3.0 branch?  Since branches are
> forever in hg, it will always be hanging around.

We'd "close" the branch, so it would exist but would not show up as an
open branch anymore.

>
> Finally, I've said this before to a few people and it's been touched on in
> this thread, but I don't think the main hangup for a 3.0 release is the
> code, but the documentation.  Unless I am mistaken, there is effectively no
> documentation of what has changed between 2.x and 3.0.  This needs to be
> near the top of the priority list for organizing for a release.

I agree with this.  Fortunately, minus the things that are listed in
the YTEPs that haven't been merged yet (i.e., "dataset" and unifying
datasets and indices) most of the changes have been developer-facing
rather than user-facing.

>
> Britton
>
>
> On Fri, Oct 4, 2013 at 6:19 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> Hi all,
>>
>> A corrollary of this is: when should the yt-3.0 branch development be
>> moved primarily into the main yt_analysis/yt repository.  This is not
>> the same as making it the main or stable line.
>>
>> Upsides: easier to switch between mainline and 3.0, easier to do
>> releases, and easier for people out there to switch and to update.
>> Downsides: higher turnover in relatively large ways on our main
>> repository, although outside of the main branch, and there are a
>> number of extant forks of 3.0 already that would be orphaned.
>>
>> I'm probably fine with this happening soon, I think.  The YTEP
>> suggests a release date for 3.0a4 of October 15, but I'd be fine
>> pushing the yt-3.0 branch into yt_analysis/yt anytime.  It's unlikely
>> that someone who doesn't want 3.0 would blindly update to 3.0 if "tip"
>> is in 3.0, so I don't think that's a huge concern.
>>
>> -Matt
>>
>> On Tue, Oct 1, 2013 at 3:50 PM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>> > Hi all,
>> >
>> > I have issued a pull request which needs to be discussed; I'd rather
>> > that be here as it's a more central location.
>> >
>> >
>> > https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dates-for-26-26x-and-30/diff
>> >
>> > I would like to propose:
>> >
>> >  * 2.6 be released on November 1, 2013, which gives several days after
>> > the "doc sprint."  I will be working on docs leading up to the doc
>> > sprint.  The code is in a good state at this point and we can release
>> > it at any time, but the documentation is the primary blocker for 2.6.
>> >  * I have added three maintenance releases, every three months, for
>> > 2.6.1, 2.6.2, 2.6.3 and 2.6.4.  This is because will *not* be
>> > deprecating the 2.x series.
>> >  * 3.0 has been added with a tentative release on January 1, 2014.  I
>> > have assessed the reliability of the code, and it seems to me that
>> > *even as it is*, it is considerably better than the 2.x line of
>> > development.  The remaining struggles are all in documentation.  A
>> > handful of operations are still outstanding -- clump finding and
>> > boolean objects most notably -- but the vast, vast majority are
>> > implemented.
>> >
>> > I have one other reason I want to push for a release: I would like to
>> > diverge the two lines of development in some substantial ways, and I
>> > do not think we can do that until we have a clear end-game.  These
>> > ways are all enumerated in these two YTEPs:
>> >
>> > https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html (by Casey)
>> >
>> > https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroifying-yt-a-bit-and
>> > (by me, not yet accepted)
>> >
>> > Both of these actually have commits outstanding, but which we have
>> > been reluctant to merge into mainline 3.0 because they will make
>> > future merging *into* 3.0 quite difficult.  They also both break
>> > backwards compat, and before we get *any* more uptake of 3.0 than we
>> > already have, I'd like to merge them in.
>> >
>> > <bold for emphasis!>
>> > An unavoidable requirement for these two YTEPs to be merged in is that
>> > a 3.0 documentation build must exist and must be up to date.  This is
>> > *my* responsibility, and I have begun to undertake it.
>> > <unbold>
>> >
>> > I'd like to resolve this by proposing we wind down development on 2.X
>> > as best we can, and instead attempt to focus resources on 3.0.  Until
>> > we do that, the biggest fish of the refactor/redesign simply can't
>> > land, which means we're in a self-perpetuating cycle of never getting
>> > to the point of being "ready."
>> >
>> > -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
>