[yt-dev] RFC: Staggered deprecation through 3.1 and 3.2

Stuart Mumford stuart at mumford.me.uk
Tue Jun 24 09:57:16 PDT 2014


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 at 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 at 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 at 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 at 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 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/20140624/e86abe45/attachment.html>


More information about the yt-dev mailing list