question re: default branch and release clone
Now that the 3.3 release clone has been created, can someone clarify what changes are allowed to go into the default branch? Is it the same policy as if the changes were going into the release clone directly (i.e. code freeze unless you have Georg's approval), or are future changes for 3.3.1 okay, or is the default branch for changes that would go into 3.4? If the policy is the same, when and how do we anticipate changing things for the default branch? Thanks, --Chris
On 26.08.2012 21:15, Chris Jerdonek wrote:
Now that the 3.3 release clone has been created, can someone clarify what changes are allowed to go into the default branch? Is it the same policy as if the changes were going into the release clone directly (i.e. code freeze unless you have Georg's approval), or are future changes for 3.3.1 okay, or is the default branch for changes that would go into 3.4? If the policy is the same, when and how do we anticipate changing things for the default branch?
Changes to the default branch must be bugfix-only. The 3.4 development only opens when the 3.3 branch is created, which happens after the release of 3.3.0 final. Changes made in default and not cherry-picked to the 3.3.0 release clone will therefore end up in 3.3.1 and 3.4. cheers, Georg
Georg Brandl wrote:
Changes to the default branch must be bugfix-only. The 3.4 development only opens when the 3.3 branch is created, which happens after the release of 3.3.0 final.
Changes made in default and not cherry-picked to the 3.3.0 release clone will therefore end up in 3.3.1 and 3.4.
Where should I put the news entry for fixes that will go to 3.3.1? The top item in Misc/NEWS is 3.3.0 RC 2. The stuff in your private clone will be released as 3.3.0, so can a 3.3.1 entry be added to the default branch of the public repo now? And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad? Petri
On 28.08.2012 06:22, Petri Lehtinen wrote:
Georg Brandl wrote:
Changes to the default branch must be bugfix-only. The 3.4 development only opens when the 3.3 branch is created, which happens after the release of 3.3.0 final.
Changes made in default and not cherry-picked to the 3.3.0 release clone will therefore end up in 3.3.1 and 3.4.
Where should I put the news entry for fixes that will go to 3.3.1? The top item in Misc/NEWS is 3.3.0 RC 2. The stuff in your private clone will be released as 3.3.0, so can a 3.3.1 entry be added to the default branch of the public repo now?
Yes.
And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad?
Sounds fine to me. Georg
And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad?
This is the standard for any security fix: such a fix would be added to 3.1.6, 3.2.4, 3.3.1, and 3.4.0, but not to 3.2.3 or 3.3.0. So version(A) > version(B) does not imply has_fix(A, F) if has_fix(B, F) (for Python releases A and B and fix F) The same would regularly happen with any bug fix, too, except we only have one bug fix branch at nearly every point in time (except that we have the 2.7 branch as well). Regards, Martin P.S. Python 3.1 will continue to receive security fixes until June 2014, 3.2 will receive them until February 2016, 3.3 until September 2017. For 2.7, a policy needs to be set after the last bug fix release of 2.7 was made.
participants (4)
-
"Martin v. Löwis" -
Chris Jerdonek -
Georg Brandl -
Petri Lehtinen