On Fri, Feb 18, 2011 at 3:19 AM, Terry Reedy <tjre...@udel.edu> wrote: > Actually, to me, the confusion is slightly worse, and the reason to change > slightly stronger, than I initially explained. Python x.y is a version of > the *language*. CPython x.y.z is an occasional marked release of an > *implementation*. > > For instance, Python 3.2 is a version of the language and stdlib. It has > been pretty well defined since new features were prohibited. > > The 3.2 docs are the specification of Python 3.2 (with a few > CPython-specific notes). The 3.2 docs will be continuously upgraded as > deficiencies are noted and fixed. As I understand it, all patches are > expected to leave the docs in an improved and buildable state, so that > updates can be built and uploaded to the site frequently (daily?). > > CPython 3.2.0 will be the first 'production' release of the CPython > implementation of Python 3.2. It will be one in a series of approximation of > an ideal bug-free 'CPython 3.2'. Some have already been released, more will > come. Like the docs, the concrete CPython 3.2 codebase will also be > continuously upgraded. For various reasons, it will probably not always be > buildable on all platforms and not always be production ready. For practical > reasons, marked releases will be spaced some months apart. > > So, for me, Python 3.2 is a now theoritically fixed version of the language. > The Python 3.2 docs document that version, but will be upgraded as mistaked, > ambiguities, and omissions are found. The CPython 3.2 codebase is an > evolving approximation of an ideal bug-free CPython 3.2 (that will never be > reached). And CPython 3.2.0 is an early snapshot release of that evolving > codebase.
I actually agree with this viewpoint, and think it would definitely be a good way to go for 3.3.0. For the 3.2 series, I think living with the ambiguity for another 6 months or so (however long it is until 3.2.1 is released) is the better choice. There are enough parts of the release process that involve the version number that we *really* shouldn't be messing with it during the RC phase. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com