Movatterモバイル変換
[0]ホーム
[Python-Dev] Versioning proposal: syntax.stdlib.bugfix
Matt Joineranacrolix at gmail.com
Sun Feb 26 04:22:54 CET 2012
Chrome does something similar. All digits keep rising in that scheme.However in your examples you can't identify whether bug fixes are to stdlibor interpreter?On Feb 26, 2012 10:07 AM, "Terry Reedy" <tjreedy at udel.edu> wrote:> We have two similar proposals, PEPs 407 and 413, to speed up the release> of at least library changes. To me, both have major problems with version> numbering.>> I think the underlying problem is starting with a long-term fixed leading> '3', which conveys no information about current and future changes (at> least for another decade).>> So I propose for consideration that we use the first digit to indicate a> version of core python with fixed grammar/syntax and corresponding> semantics. I would have this be stable for at least two years. It seems> that most current syntax proposals amount to duplication of current> function to suite someone's or some people's stylistic preference. My> current view is that current syntax in mostly good enough, the> implementation thereof is close to bug-free, and we should think carefully> about changes.>> We could then use the second digit to indicate library version. The .0> library version would be for a long-term support version. The library> version could change every six months, but I would not necessarily fix it> at any particular interval. If we have some important addition or upgrade> at four months, release it. If we need another month to include an> important change, perhaps wait.>> The third digit would be for initial (.0) and bugfix releases, as at> present. Non .0 bugfix releases would mostly be for x.0 long-term> syntax+library versions. x.(y!=0).0 library-change-only releases would only> get x.(y!=0).1 bugfix releases on an 'emergency' basis.>> How this would work:>> Instead of 3.3.0, release 4.0.0. That would be followed by 4.0.1, 4.0.2,> etc, bugfixes, however often we feel like it, until 5.0.0 is released.>> 4.0.0 would also be followed by 4.1.0 with updated stdlib in about 6> months, then barring mistakes, 4.2.0, etc, again until 5.0.0.>> A variation of this proposal would be to prefix '3.' to core.lib.fix. I> disfavor that for 3 reasons.> 1. It is not needed to indicate 'not Python 2' as *any* leading digit> greater than 2 says the same.> 2. It makes for a more awkward 4 level number.> 3. It presupposes a 3 to 4 transition something like the 2 to 3> transition. However, I am dubious about for more than one reason (another> topic for another post).>> --> Terry Jan Reedy>> ______________________________**_________________> Python-Dev mailing list>Python-Dev at python.org>http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>> Unsubscribe:http://mail.python.org/**mailman/options/python-dev/**> anacrolix%40gmail.com<http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com>>-------------- next part --------------An HTML attachment was scrubbed...URL: <http://mail.python.org/pipermail/python-dev/attachments/20120226/463302da/attachment.html>
More information about the Python-Devmailing list
[8]ページ先頭