Warning
At present, this includes all the material from the Jython guide, but predominantly describes the CPython process with CPython examples. The process is the one Jython will move to: some applies already and the rest is important for us to get clear. It's just that the examples are a bit incongruous for Jython.
The responsibilities of a core developer shift based on what kind of branch of Jython a developer is working on and what stage the branch is in.
To clarify terminology, Jython uses a major.minor.micro nomenclature
for production-ready releases. So for Jython 3.1.2 final, that is a major
version of 3, a minor version of 1, and a micro version of 2.
- new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;
- new minor versions are feature releases; they get released roughly every 18 months, from the current :ref:`in-development <indevbranch>` branch;
- new micro versions are bugfix releases; they get released roughly every 6 months, although they can come more often if necessary; they are prepared in :ref:`maintenance <maintbranch>` branches.
We also publish non-final versions which get an additional qualifier: :ref:`alpha`, :ref:`beta`, :ref:`release candidate <rc>`. These versions are aimed at testing by advanced users, not production use.
There is a branch for each feature version, whether released or not (e.g. 2.7, 3.5). Development is handled separately for Python 2 and Python 3: no merging happens between 2.x and 3.x branches.
The master branch is the branch for the next feature release; it is
under active development for all kinds of changes: new features, semantic
changes, performance improvements, bug fixes.
In a process based on Mercurial, the branch is identifies as default.
It is the branch :ref:`checked out <checkout-jy>` by default by Mercurial.
At some point during the life-cycle of a release, a new :ref:`maintenance branch <maintbranch>` is created to host all bug fixing activity for further micro versions in a feature version (3.6.1, 3.6.2, etc.).
For versions 3.4 and before, this was conventionally done when the final release was cut (for example, 3.4.0 final).
Starting with the 3.5 release, we create the release maintenance branch (e.g. 3.5) at the time we enter beta (3.5.0 beta 1). This allows feature development for the release 3.n+1 to occur within the master branch alongside the beta and release candidate stabilization periods for release 3.n.
A branch for a previous feature release, currently being maintained for bug fixes. There are usually two maintenance branches at any given time: one for Python 3.x and one for Python 2.x. Only during the beta/rc phase of a new minor/feature release will there be three active maintenance branches, e.g. during the beta phase for Python 3.6 there were master, 3.6, 3.5, and 2.7 branches open. At some point in the future, Python 2.x will be closed for bug fixes and there will be only one maintenance branch left.
The only changes allowed to occur in a maintenance branch without debate are bug fixes. Also, a general rule for maintenance branches is that compatibility must not be broken at any point between sibling minor releases (3.5.1, 3.5.2, etc.). For both rules, only rare exceptions are accepted and must be discussed first.
Sometime after a new maintenance branch is created (after a new minor version is released), the old maintenance branch on that major version will go into :ref:`security mode <secbranch>`, usually after one last maintenance release at the discretion of the release manager. For example, the 3.4 maintenance branch was put into :ref:`security mode <secbranch>` after the 3.4.4 final maintenance release following the release of 3.5.1.
A branch less than 5 years old but no longer in maintenance mode is a security branch.
The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch. You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing.
Commits to security branches are to be coordinated with the release manager for the corresponding feature version, as listed below in the Summary. Any release made from a security branch is source-only and done only when actual security patches have been applied to the branch.
There are 5 open branches right now in the Git repository:
Warning
CPython-specific
- the
masterbranch accepts features and bugs fixes for the future 3.7.0 feature release (RM: Ned Deily) - the
3.6branch accepts bug fixes for future 3.6.x maintenance releases (RM: Ned Deily) - the
3.5branch accepts security fixes for future 3.5.x security releases (RM: Larry Hastings) - the
3.4branch accepts security fixes for future 3.4.x security releases (RM: Larry Hastings) - the
2.7branch accepts bug fixes for future 2.7.x maintenance releases (RM: Benjamin Peterson)
Warning
Jython information out of date.
See also the :ref:`Status of Python branches <branchstatus>`.
- the
defaultbranch holds the future 2.7 version and descends from2.5 - the
2.5branch holds bug fixes for future 2.5.x maintenance releases and descends from2.2 - the
2.2branch holds security fixes for future 2.2.x security releases
Based on what stage the :ref:`in-development <indevbranch>` version of Python is in, the responsibilities of a core developer change in regards to commits to the :abbr:`VCS (version control system)`.
The branch is in this stage when no official release has been done since the latest final release. There are no special restrictions placed on commits, although the usual advice applies (getting patches reviewed, avoiding breaking the buildbots).
Alpha releases typically serve as a reminder to core developers that they need to start getting in changes that change semantics or add something to Python as such things should not be added during a Beta. Otherwise no new restrictions are in place while in alpha.
After a first beta release is published, no new features are accepted. Only bug fixes can now be committed. This is when core developers should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases.
Being in beta can be viewed much like being in RC but without the extra overhead of needing commit reviews.
Please see the note in the In-development (main) branch section above for new information about the creation of the 3.5 maintenance branch during beta.
A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point.
You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core developer.
When a final release is being cut, only the release manager (RM) can make changes to the branch. After the final release is published, the full :ref:`development cycle <stages>` starts again for the next minor version.