Hello Wolfgang, On Sat, 4 Nov 2017 12:25:57 +0100 (CET) tds...@mailbox.org wrote: > Hello, > > one of my long standing ideas to improve Python is to adjust the > release cycle and version number handling. In short, to simplify it.
There has been ample discussion in the past about changing our release cycle one way or another. In short, the meta-problem is there are many contradicting interests which would each favour a different solution to the problem. See for example this PEP (ultimately rejected): https://www.python.org/dev/peps/pep-0407/ and the discussion that ensued: https://mail.python.org/pipermail/python-dev/2012-January/thread.html#115591 I haven't read your proposal in detail, but I suspect that it may be vulnerable to some of the same objections. The big objection being that a significant part of our ecosystem (that is, to put it roughly, the more corporate-minded segment, though I believe it is a simplification and may include other segments, such as Debian stable users and maintainers) doesn't want to deal more frequent feature releases. Regards Antoine. > > This is the first draft of the idea: > > Proposal to change Python version release cycle > =============================================== > > > Goal > ---- > > Increment the major version number more frequently for every new language > feature release. > Change Python feature version counting from "major.minor" to "major". > > This is simpler, better to handle compatibility and allows adding new > library features more frequently. > > The current Python version scheme is Major.Minor.Patch this will be kept > but the major version number will be incremented faster and for every > language feature release as it is now for the minor number. > > For example today the minor version number is increased for every big release > done in 1,5 year cycle. In this new language features with new keywords can > appear, new libraries can be included and other C level API changes can > happen. > There backward compatible feature improvements and new features also backward > incompatible can happen. > > I suggest to change this to increment the major version for every new release > of the 1,5 year cycle. > And allow new Python standard library backward compatible changes for every > minor release cycle every 6 months. > > Start with this from Python version 4 on. > > > Benefit > ------- > > Clear separation of new language features and C API changes and new > backward compatible feature additions. > > So for a major version on Python level new keywords can be added, build ins > can be added or removed and the C API can be changed (new features or other > incompatible changes). > > For a minor version new standard libraries can be added and API can be > improved > in a backward compatible way. This can be done more frequently for example in > a 0,5 year cycle. Allowing the Python library part to improve in a higher > rate. > > For a patch version only none breaking bug and security fixes are allowed. > (Same as it is now, or even a little bit stricter) > > With this change there is a clear separation of new language Features which > are also tracked by other Python implementations and new library features. > This can be seen very easy by only looking at the Python major version. > The C API level is included in this standard and is not allowed to change > in a minor version as it is now. This is because booth the Python language > and the C API of CPython implementation is a standard and tracked by other > implementations. For them it is easy to say I am compatible to Version 4. > For everyone in computer business it is clear what is meant. > > The Python standard library can be improved in a higher rate because backward > compatible feature changes are allowed in a higher rate for minor versions. > Also provisional libraries can be improved in a faster rate for every minor > version. (for example every 6 months instead of 1,5 years) > > For Unix in the Python executable the major version can be appended and this > specifies the Python language standard used. This is done already but most of > the time only EXECUTABLEmajor.minor is useful. Also more complicated to handle > as a simple Number. Can be problematic on some platforms because of the dot > ".". > > Python major version every 1,5 years (same as it is now for major.minor). > Python minor version every 6 months (to allow faster standard library > changes). > Python patch version as needed (to fix only bugs and security related stuff) > > This can solve the problem of adding something as a standard library and then > this is the dead of the library because it cannot be improved any further > in a higher update rate. > The Python standard library should not be a dead end for a library after > inclusion. This allows Python code to improve faster than the C code. > This is needed to include new features faster and because we have more > people capable in Python programming than for C in the Python community. > > On C level the compatibility distinction is simple only track the major > version and no longer a mixture between major and major.minor compatibility. > > > Risk > ---- > > Minimal because to track features the major.minor version already has to be > tracked. > It is a change some assumptions about Python versions are at this point no > longer valid. > On C level external libraries and wrappers must adopt it and changes are > needed. > > > Open questions > -------------- > > The exact release cycle for minor, can also be every 4 months if needed. > Clear separation what is part of the language standard and what is part > of the C API. > Some modules, for example "sys" can also be part of the language Standard > and should not change between minor versions. > > The difference between the stable C API and that for every minor version > can be removed. There is only one C API guarantee for a major version > and it does not change for a minor version. > > > None goals > ---------- > > Change the release cycle of 1,5 years for new big releases. > Change the versioning scheme to something other than "major.minor.patch". > New big ground breaking changes to everything. > To complicate something. > > > Regards, > > Wolfgang > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
