Hi, I see your problem. I don't think your '2014' idea would be compatible with http://legacy.python.org/dev/peps/pep-0386/ I would say an rc tag has less stigma or a .dev pre release, although pypi won't install that by default. Stuart On 24 Jun 2014 17:38, "Matthew Turk" <matthewturk@gmail.com> wrote:
I think Britton covered the halos, but the VR works as-is. As far as 3.0beta, I'm a bit nervous about that as we want to avoid the situation where we are in beta for 1+ years... I am worried about the perception of a "beta" tag. Is that overblown? Would calling it "yt-3.0-2014" work?
On Tue, Jun 24, 2014 at 10:32 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Do the old VR and halo interfaces work? Not much effort has gone into porting them, I think.
On Tuesday, June 24, 2014, Sam Skillman <samskillman@gmail.com> wrote:
I'm +1 on this, particularly since I'm at fault for not pushing on the
VR
as much as I'd like to.
On Tue, Jun 24, 2014 at 7:44 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
One thing we really tried to do with 3.0 was break all the APIs we thought we'd need to before release. This included things like ds/pf, index/hierarchy, the way data selections were made, etc.
It's starting to become clear that we are approaching maturity at different rates in these initiatives. I am wondering if perhaps we should de-couple the release from all of the API breakages, and instead note which interfaces we know are going to change in the future.
Pragmatically, what this would mean is:
* Release a 3.0 with the old VR and halo finding interfaces * Release a 3.1 with either the new VR or the new halo finding (or
both)
* Do the same for 3.2
This doesn't fit with the usual "major numbers are where APIs break" philosophy that comes from semantic versioning, but I think from the perspective of pragmatism, if we identify those sections of the code that are *going* to change, and we pitch 3.0 as the first part of a staged release of totally rewritten infrastructure, we can likely come out okay.
I'd like to put this out there for discussion.
-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