<br><br><div class="gmail_quote">On Fri, Feb 24, 2012 at 13:23, Georg Brandl <span dir="ltr"><<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am <a href="tel:24.02.2012%2018" value="+12402201218">24.02.2012 18</a>:46, schrieb Antoine Pitrou:<br>
<div class="im">><br>
> Hello,<br>
><br>
> On Sat, 25 Feb 2012 03:24:27 +1000<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> To allow the PEP 407 authors to focus on making the case for doing<br>
>> full CPython releases every 6 months (including language spec<br>
>> updates), I've created PEP 413 as a competing proposal.<br>
>><br>
>> It leaves the current language versioning (and rate of change) alone,<br>
>> while adding an additional date based standard library version number<br>
>> and adopting a new development workflow that will allow "standard<br>
>> library" releases to be made alongside each new maintenance release.<br>
><br>
> Overall, I like the principle of this PEP, but I really dislike the<br>
> dual version numbering it introduces. Such a numbering scheme will be<br>
> cryptic and awkward for anyone but Python specialists.<br>
<br>
</div>I agree.<br></blockquote><div><br></div><div>Ditto. You could also mention that this could help other VMs by getting compatibility fixes into the stdlib faster than they do currently, letting other VMs hit minor release compat faster.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> I also think the branches and releases management should be even<br>
> simpler:<br>
><br>
> - 2.7: as today<br>
> - 3.3: bug fixes + stdlib enhancements<br>
> - default: language enhancements / ABI-breaking changes<br>
><br>
> Every 6 months, a new stdlib + bugfix release would be cut (3.3.1,<br>
> 3.3.2, etc.), while language enhancement releases (3.4, 3.5...) would<br>
> still happen every 18 months.<br>
<br>
</div>Sorry, I don't think that's feasible at all. For one, it removes the<br>
possibility to target a stable set of features for a longer time.<br>
<br>
In short, the only usable solution I see is PEP 407-style versioning<br>
with language changes only in LTS releases.</blockquote><div><br></div><div>While I personally would rather switch to making the major version mean a language change has occurred instead of reserving it for completely backwards-incompatible language changes, I know history is going to lead people killing that idea, so I agree with Georg on using an LTS delineation for language-changing releases and keeping them patched up until the next LTS is better. IOW we cut 3.3.0 as an LTS and then have 3.4 and 3.5 only contain stdlib changes while also releasing 3.3.1 and 3.3.2 for bugfixes on 3.3. There would be no micro releases for 3.4 and 3.5 (sans an emergency brown bag release) since the next release is coming in 6 months anyway with any previous bugfixes + changes that might break compatibility with 3.3 in the stdlib.</div>
<div><br></div><div>My worry with Antoine's approach is that it will cause pain for people by us mucking around with stdlib stuff that will break compatibility somehow, preventing some people from upgrading immediately, but out in the cold when it comes to bugfixes since they can't grab the next release yet. The only way for Antoine's approach to work is if we made some release count guarantee (like 3 releases) for anything that might break someone, making stdlib-only releases more accumulative then iterative.</div>
</div>