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