[Python-Dev] PEP 407 / splitting the stdlib (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Wed Jan 18 13:30:13 CET 2012
- Previous message: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
- Next message: [Python-Dev] PEP 407 / splitting the stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Le mercredi 18 janvier 2012 à 21:26 +1000, Nick Coghlan a écrit :
I'm also wholly in agreement with Ezio that using the same versioning scheme for both full releases and interim releases is thoroughly confusing for users
It's a straight-forward way to track the feature support of a release. How do you suggest all these "sys.version_info >= (3, 2)" - and the corresponding documentation snippets a.k.a "versionadded" or "versionchanged" tags - be spelt otherwise?
for example, I consider Red Hat's completely separate branding and versioning for Fedora and RHEL a better model for end users
It's not only branding and versioning, is it? They're completely different projects with different goals (and different commercial support).
If you're suggesting we do only short-term releases and leave the responsibility of long-term support to another project or entity, I'm not against it, but it's far more radical than what we are proposing in the PEP :-)
Instead, if the proposal involves instituting a PEP 3003 style moratorium (i.e. stdlib changes only) for all interim releases, then we're essentially talking about splitting the versioning of the core language (and the CPython C API) and the standard library. If we're going to discuss that, we may as well go a bit further and just split development of the two out onto separate branches, with the current numbering scheme applying to full language version releases and switching to a date-based versioning scheme for the standard library (i.e. if 3.3 goes out in August as planned, then it would be "Python 3.3 with the 12.08 stdlib release").
Well, you're opposing the PEP on the basis that it's workforce-intensive but you're proposing something much more workforce-intensive :-)
Splitting the stdlib:
- requires someone to do the splitting (highly non-trivial given the interactions of some modules with interpreter details or low-level C code)
- requires setting up separate resources (continuous integration with N stdlib versions and M interpreter versions, for example)
- requires separate maintenance and releases for the stdlib (but with non-trivial interaction with interpreter maintenance, since they will affect each other and must be synchronized for Python to be usable at all)
- requires more attention by users since there are now two release schedules and independent version numbers to track
The former two are one-time costs, but the latter two are recurring costs.
Therefore, splitting the stdlib is much more complicated and involved than many people think; it's not just "move a few directories around and be done". And it's not even obvious it would have an actual benefit, since developers of other implementations are busy doing just that (see Jeff Hardy's message in this thread).
Regards
Antoine.
- Previous message: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
- Next message: [Python-Dev] PEP 407 / splitting the stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]