On Mon, Oct 7, 2013 at 6:01 AM, Britton Smith
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
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
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-dat...
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-astroify... (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.
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@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