[yt-dev] Proposed: release dates for 2.6, 2.6.x, and 3.0
Britton Smith
brittonsmith at gmail.com
Mon Oct 7 03:01:03 PDT 2013
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.
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.
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.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20131007/323c383b/attachment.html>
More information about the yt-dev
mailing list