Documenting branch policy
[cc'ing pydotorg since this involves a change to web content, but followup to python-dev please] Has anyone taken the time to sit down and document the development process surrounding release and maintenance branches? Speaking as an infrequent contributor to Python, it's never been entirely clear to me how to deal with branches. Seems to me like adding a paragraph or two to this page: http://www.python.org/dev/process.html would be a good start. Here's a first crack, based largely on guesswork, extrapolation from my day job (which also uses maintenance branches), and common sense: """ <h4>CVS Branch Policy</h4> <p>The Python development process uses CVS branches for a couple of purposes: <ul> <li>maintenance branches, for minor Python releases (2.2.3, 2.3.1, etc.) <li>release branches, for the exclusive use of the release manager(s) <li>feature branches, for large, disruptive additions/changes that take a long time to stabilize </ul> <h5>Maintenance branches</h5> <p>Every major Python version (2.1, 2.2, 2.3, etc.) is accompanied by a <em>maintenance branch</em>. Minor Python releases are always made from a maintenance branch -- e.g. Python 2.2.3 was made on the <code>release22-maint</code> branch, and Python 2.3.1 will be made on <code>release23-maint</code>. Maintenance branches are long-lived; they remain open as long as minor releases based on the corresponding major release are a possibility. Maintenance branches are for bug fixes <em>only</em>; maintaining backwards compatibility at every level is imperative. (In particular, all extension modules and bytecode for Python 2.<em>x</em>.<em>y</em> must continue to work with Python 2.<em>x</em>.<em>y+1</em> -- binary compatibility in the C API and bytecode must be maintained.)</p> <p>Any Python developer may checkin bug fixes on a maintenance branch; it is the release manager's responsibility to create the maintenance branch after releasing a new major Python version.</p> <h5>Release branches</h5> <p>Every release up to and including the final release for a new major Python version is accompanied by a <em>release branches</em>. For example, there were release branches for 2.3a1, 2.3a2, 2.3b1, 2.3b2, 2.3c1, and 2.3 itself; there will <em>not</em> be release branches for 2.3.1, 2.3.2, and so forth. Release branches allow the release manager to make small, last-minute changes without being affected by mainline development. It is the release manager's responsibility to merge changes from each release branch back onto the trunk after the release is finished. <p>Unless you are one of the release managers for a new major Python version, you should have nothing to do with release branches.</p> <h5>Feature branches</h5> <p>Occasionally, a new feature will be deemed large and disruptive enough that it will be added on a branch. For example, the "new-style classes" feature of Python 2.2 was added on <code>descr-branch</code> (the non-obvious name stems from <em>descriptors</em>, the new C-level data structure underlying new-style classes), which took several months to stabilize before it was merged onto the trunk. Managing a feature branch is tricky business, and the longer it takes to stabilize the new feature, the trickier it gets. <p>Feature branches are generally created and used by a single developer. Do not create a feature branch without discussing it on python-dev.</p> """ Please let me know how close this is to describing reality! Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ Cheops' Law: Nothing *ever* gets built on schedule or within budget.
Greg Ward <gward@python.net> writes:
Has anyone taken the time to sit down and document the development process surrounding release and maintenance branches?
You mean PEP 6 and PEP 102?
Maintenance branches are for bug fixes <em>only</em>;
This question is heavily debated. Alex Martelli, for example, favours a policy where new (in a strict sense) features are acceptable if they don't break anything, and are "minor", in some sense.
maintaining backwards compatibility at every level is imperative. (In particular, all extension modules and bytecode for Python 2.<em>x</em>.<em>y</em> must continue to work with Python 2.<em>x</em>.<em>y+1</em> -- binary compatibility in the C API and bytecode must be maintained.)</p>
Even that requirement got dropped at one time, on grounds of the specific API being irrelevant for all practical applications.
<p>Any Python developer may checkin bug fixes on a maintenance branch; it is the release manager's responsibility to create the maintenance branch after releasing a new major Python version.</p>
The typical guidelines apply: If in doubt, post to SF. Regards, Martin
On 07 September 2003, Martin v. Löwis said:
Greg Ward <gward@python.net> writes:
Has anyone taken the time to sit down and document the development process surrounding release and maintenance branches?
You mean PEP 6 and PEP 102?
Ahh, PEP 6 is what I was looking for. Never mind my proposed change then. Thanks -- Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ "Question authority!" "Oh yeah? Says who?"
On 7-sep-03, at 21:15, Martin v. Löwis wrote:
Maintenance branches are for bug fixes <em>only</em>;
This question is heavily debated. Alex Martelli, for example, favours a policy where new (in a strict sense) features are acceptable if they don't break anything, and are "minor", in some sense.
With Python 2.3 included in MacOSX 10.3 I would be heavily opposed to this. I know, I've done it myself all the time in the past (with MacPython for OS9), but with Python 2.3 we have the situation that the majority of Python installations (I think it's safe to take the guess that MacOSX 10.3 installations will soon outnumber all other Pythons together) will stay at 2.3 until the next release of MacOSX. This means that by adding even the slightest bit of functionality you will make life difficult for developers: they themselves will probably track Python releases, but their customers most likely won't. Note that the MacPython infrastructure (bundlebuilder and such) really invites people to distribute their applications to third parties. And judging by the discussions on pythonmac-sig a lot of people are already doing this. Even bug fixes already have an impact (because the developer won't see a bug that will show up on the deployment machine), but adding functionality would exacerbate the issue. -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
Jack Jansen wrote:
On 7-sep-03, at 21:15, Martin v. Löwis wrote:
This question is heavily debated. Alex Martelli, for example, favours a policy where new (in a strict sense) features are acceptable if they don't break anything, and are "minor", in some sense.
With Python 2.3 included in MacOSX 10.3 I would be heavily opposed to this. I know, I've done it myself all the time in the past (with MacPython for OS9), but with Python 2.3 we have the situation that the majority of Python installations (I think it's safe to take the guess that MacOSX 10.3 installations will soon outnumber all other Pythons together) will stay at 2.3 until the next release of MacOSX.
It's been a huge pain with 2.2 vs. 2.2.1 even: all stuff written for 2.2.1 that uses booleans does _not_ work on plain 2.2, which is what's installed on OSX 10.2. Which sortof kills the advantage of having a Python installed with the OS to begin with. In retrospect, I would have been strongly against adding booleans to 2.2.1 for this reason. Apart from real bugs, I think every program that works on 2.x.y should work on 2.x.z, regardless of whether y > z or y < z. Just
Just van Rossum writes:
It's been a huge pain with 2.2 vs. 2.2.1 even: all stuff written for 2.2.1 that uses booleans does _not_ work on plain 2.2, which is what's
No code written for 2.2.1 should be using bool(), True, or False; those were not documented in 2.2.1 *at all* as far as I can tell. The description of bool() was added to the docs in 2.2.3, and I'm not sure why, though it is noted that it was added in 2.2.1. I'd be happy to rip it out of the documentation, or add a stronger compatibility warning, for 2.2.4.
installed on OSX 10.2. Which sortof kills the advantage of having a Python installed with the OS to begin with. In retrospect, I would have been strongly against adding booleans to 2.2.1 for this reason. Apart from real bugs, I think every program that works on 2.x.y should work on 2.x.z, regardless of whether y > z or y < z.
Depending on just what you mean "every program that works", this could completely prevent these bugfix releases. We might not be able to remove a core dump since it would allow code to run that was not run before, thereby changing the behavior of the code. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
[Just van Rossum]
Apart from real bugs, I think every program that works on 2.x.y should work on 2.x.z, regardless of whether y > z or y < z.
[Fred Drake]
Depending on just what you mean "every program that works", this could completely prevent these bugfix releases. We might not be able to remove a core dump since it would allow code to run that was not run before, thereby changing the behavior of the code.
JvR did qualify it with: "apart from real bugs". The only question is how "real" does it have to be. I think all of the following should be fair game: * not matching documented behavior (for example: '%F" % x) * usability fixes * performance issues (strptime caching for example) * something that can only be crashed by an obscure case (Armin Rigo's itertools.izip hack) * leaks (the massive leak in the array module) * security fixes * enhancing the docs (chm files, examples, new docs, etc.) * adding capabilities to standalone Tools/scripts or IDLE * updates to separately maintained packages (like "email") so that between major releases, Python won't get terribly far behind the stable releases of the package. I think of micro releases as being the same as service patches which are supposed to be painless upgrades that any admin or user can load without fear of breaking existing code. That should likely be the standard rather than requiring that all programs work irrespective of the micro version. If an application is affected by a bug in an earlier micro version, it isn't terribly unreasonable to ask the users to download the service patch which should be relatively effortless as compared with installing a new major release. Raymond Hettinger
* not matching documented behavior (for example: '%F" % x)
Depends on how you fix these. Fixing the code may break more code than fixing the docs (assuming the mismatch existed for a long time)!
* usability fixes
What are these? Seems like a loophole the size of a large truck.
* performance issues (strptime caching for example) * something that can only be crashed by an obscure case (Armin Rigo's itertools.izip hack) * leaks (the massive leak in the array module) * security fixes
But every attempt should be made to fix these without changing APIs.
* enhancing the docs (chm files, examples, new docs, etc.) * adding capabilities to standalone Tools/scripts or IDLE
Questionable, if these are installed. Esp. now that IDLE is part of the standard library.
* updates to separately maintained packages (like "email") so that between major releases, Python won't get terribly far behind the stable releases of the package.
Again, this should be done with the utmost backwards compatibility in mind, and even then, new features are new features, and thus may cause the problem Jack and Just warn about.
I think of micro releases as being the same as service patches which are supposed to be painless upgrades that any admin or user can load without fear of breaking existing code. That should likely be the standard rather than requiring that all programs work irrespective of the micro version.
If an application is affected by a bug in an earlier micro version, it isn't terribly unreasonable to ask the users to download the service patch which should be relatively effortless as compared with installing a new major release.
Right, but keep in mind that few people except hardcore Python users are going to upgrade their Python, no matter how painless, just to run some small piece of software they downloaded. They'll just toss the download as one of so many broken things, proof that free software sucks. --Guido van Rossum (home page: http://www.python.org/~guido/)
At 04:13 PM 9/8/03 -0700, Guido van Rossum wrote:
Right, but keep in mind that few people except hardcore Python users are going to upgrade their Python, no matter how painless, just to run some small piece of software they downloaded. They'll just toss the download as one of so many broken things, proof that free software sucks.
I've even seen *developers* do this... Somebody who works in my department here griped about PEAK not working on their machine and when I went to troubleshoot it, I found they had a lesser version (2.2.1) of Python than the docs explicitly required (2.2.2, which fixed a couple of relevant new-style class bugs). (Makes me think I should put some code in to check the Python version and exit with a helpful error message.) It does suggest that being able to specify the version of Python required by a script or module, would be a helpful idiom. sys.requireversion(), perhaps? Guess I should make a quick check to be sure you haven't already used the time machine and put this in... :) Of course, the sad bit is that even if there were a sys.requireversion(), it wouldn't be in the versions where it was actually needed: the older ones!
In article <5.1.1.6.0.20030908195222.01f1a860@telecommunity.com>, "Phillip J. Eby" <pje@telecommunity.com> wrote:
It does suggest that being able to specify the version of Python required by a script or module, would be a helpful idiom. sys.requireversion(), perhaps? Guess I should make a quick check to be sure you haven't already used the time machine and put this in... :)
Of course, the sad bit is that even if there were a sys.requireversion(), it wouldn't be in the versions where it was actually needed: the older ones!
Ok, so what's needed isn't a new sys.feature, it's some short boilerplate code you could include in all your python apps, to make sure anyone who tries to run it on an old system is informed of the problem. Something like: import sys class PythonTooOld(Exception): pass if sys.version < '2.2': raise PythonTooOld, 'This code needs Python 2.2 or greater.' -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science
Phillip J. Eby writes:
It does suggest that being able to specify the version of Python required by a script or module, would be a helpful idiom. sys.requireversion(), perhaps? Guess I should make a quick check to be sure you haven't already used the time machine and put this in... :)
I'm not aware of any such thing.
Of course, the sad bit is that even if there were a sys.requireversion(), it wouldn't be in the versions where it was actually needed: the older ones!
Comparison with sys.version_info would be trivial, and seems sufficient: if sys.version_info < (2,2,2): print "Get a newer version of Python!" else: main() -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
Fred L. Drake, Jr. said:
Comparison with sys.version_info would be trivial, and seems sufficient:
if sys.version_info < (2,2,2): print "Get a newer version of Python!" else: main()
FWIW - I often use something close to this near the top of my own modules (realizing that it gets skipped when the -O option is provided): assert sys.version_info >= (2,2,2), 'requires Python 2.2.2 or better' Matthew Barnes
On Tuesday 09 September 2003 02:02 am, Phillip J. Eby wrote: ...
Of course, the sad bit is that even if there were a sys.requireversion(), it wouldn't be in the versions where it was actually needed: the older ones!
Actually this would "fail-RIGHT": on older versions the program would die right there with an AttributeException and a traceback about a line such as sys.requireversion('2.3.2'), which is already a clear enough indication of exactly what is wrong -- on newer ones with an even clearer exception, of course. In any case, one could dress up the sys.requireversion call in a try/except to make its absence no problem. Alex
[Raymond Hettinger]
* not matching documented behavior (for example: '%F" % x)
[Guido]
Depends on how you fix these. Fixing the code may break more code than fixing the docs (assuming the mismatch existed for a long time)!
Such as the socket mismatch that was fixed in (IIRC) 1.6, to loud complaints from half the network programming world? This still bites occasionally when old cord has to be brought forward to more recent versions (though, of course, it isn't hard to make the necessary changes). [...]
* updates to separately maintained packages (like "email") so that between major releases, Python won't get terribly far behind the stable releases of the package.
Again, this should be done with the utmost backwards compatibility in mind, and even then, new features are new features, and thus may cause the problem Jack and Just warn about.
Yup. Any potential for code breakage is going to cause somebody somewhere a certain amount of pain. It's these edge cases that cause most of the problems, since overall the version-to-version compatibility picture is actually remarkably good. But people will cheerfully ignore the 99.99% of their code that *doesn't* break, and bitch about the little bits that do :-)
I think of micro releases as being the same as service patches which are supposed to be painless upgrades that any admin or user can load without fear of breaking existing code. That should likely be the standard rather than requiring that all programs work irrespective of the micro version.
If an application is affected by a bug in an earlier micro version, it isn't terribly unreasonable to ask the users to download the service patch which should be relatively effortless as compared with installing a new major release.
Right, but keep in mind that few people except hardcore Python users are going to upgrade their Python, no matter how painless, just to run some small piece of software they downloaded. They'll just toss the download as one of so many broken things, proof that free software sucks.
If you want something to be true sufficiently hard, anything convenient will be seen as supporting evidence. Raymond did, however, pinpoint the reason why I haven't yet started using True and False. what-*me*-conservative-ly y'rs - steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/
[Guido]
Depends on how you fix these. Fixing the code may break more code than fixing the docs (assuming the mismatch existed for a long time)!
[Steve]
Such as the socket mismatch that was fixed in (IIRC) 1.6, to loud complaints from half the network programming world? This still bites occasionally when old cord has to be brought forward to more recent versions (though, of course, it isn't hard to make the necessary changes).
That was not a micro release. I'm glad we fixed that one then; now it would be a much bigger disaster. (And it was not a matter of adjusting to the docs, but adjusting to the fact that not all socets deal with host/port pairs.)
[...]
Yup. Any potential for code breakage is going to cause somebody somewhere a certain amount of pain. It's these edge cases that cause most of the problems, since overall the version-to-version compatibility picture is actually remarkably good. But people will cheerfully ignore the 99.99% of their code that *doesn't* break, and bitch about the little bits that do :-)
For people with a large code base and real customers, the only working approach is long, careful testing with each new Python release. Hence the call for Python-in-a-tie. (Though I haven't heard much about that recently -- I've even heard a call to upgrade the tie to 2.3.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 2003-09-08 at 18:29, Raymond Hettinger wrote:
* updates to separately maintained packages (like "email") so that between major releases, Python won't get terribly far behind the stable releases of the package.
You have to take things on a case-by-case basis. I actually agonized quite a bit about the email package in 2.2, but after discussing things with Guido and the mimelib community, there was general consensus that not fixing/upgrading the package was worse than doing so. But I doubt we'll do the same thing for Python 2.3, because the package is more stable now, has been integrated longer, and the planned changes are probably more radical. This does point out a problem with the batteries-included philosophy though: it's hard to upgrade packages that come with Python. Say we release email 3.0 and you want to use it in Python 2.3, what do you do? You can't just do a distutils install, because site-packages is searched after the standard library. I think we need more flexibility in installing distutils packages, so we can install in various locations that override standard packages (e.g. user-centric, system-centric, etc.). In general though, it's a good thing to default to a policy where micro releases are bug fixes only. Given the reality of the resources available, time between major releases, and the fact that Python development is a wholly volunteer effort, some amount of ugliness is bound to invade the process. That's where the BDFL uses his judgement to make a decision and we live with it. Take the True/False thing. OOH, it was a new feature added to a micro release. OTOH it was backward compatible, helped future compatibility, and was easily coded around to avoid micro-version skew. Taken as a whole, and given when the decision was made, it was probably a good one although it caused a little bit of pain. -Barry
Barry Warsaw wrote This does point out a problem with the batteries-included philosophy though: it's hard to upgrade packages that come with Python. Say we release email 3.0 and you want to use it in Python 2.3, what do you do? You can't just do a distutils install, because site-packages is searched after the standard library. I think we need more flexibility in installing distutils packages, so we can install in various locations that override standard packages (e.g. user-centric, system-centric, etc.).
The approach taken by the XML add-on package doesn't seem to be the right approach, either. At the moment your choices are to manually install the new code over the old, or else have a separate install area that's manually added to the start of the PYTHONPATH (this is what mailman does, right?) Neither of these approaches seem ideal. The latter is what I do for various systems that need newer versions of packages that are bundled with python, it'd be nice if there was a better way - but I can't see one. Anthony
[Barry Warsaw]
... This does point out a problem with the batteries-included philosophy
I was still basically asleep when I saw this msg, and my bleary eyes first read that as "barriers-included".
though: it's hard to upgrade packages that come with Python.
Indeed. Batteries, barriers, same thing <wink>.
On Tue, 2003-09-09 at 11:18, Anthony Baxter wrote:
The approach taken by the XML add-on package doesn't seem to be the right approach, either. At the moment your choices are to manually install the new code over the old, or else have a separate install area that's manually added to the start of the PYTHONPATH (this is what mailman does, right?)
Right, and it sucks because there are multiple top-level entry points into the system (e.g. command line and cron scripts) and each has to mangle the path very early on. Then there's the pain of not being able to run for the source directory because the configure/install procedure sets up the path hacking module with the proper paths. Blech. -Barry
Anthony Baxter <anthony@interlink.com.au> writes:
The approach taken by the XML add-on package doesn't seem to be the right approach, either. At the moment your choices are to manually install the new code over the old, or else have a separate install area that's manually added to the start of the PYTHONPATH (this is what mailman does, right?)
Are you referring to PyXML here? It allows to extend/replace the existing library with neither copying the new code over the old nor with adding anything to PYTHONPATH. Instead, the core library expects to be replaced, and is actively looking for a replacement. Regards, Martin
"Jack" == Jack Jansen <Jack.Jansen@cwi.nl> writes:
Jack> On 7-sep-03, at 21:15, Martin v. Löwis wrote: >>> Maintenance branches are for bug fixes >>> <em>only</em>; >> >> This question is heavily debated. Alex Martelli, for example, favours >> a policy where new (in a strict sense) features are acceptable if they >> don't break anything, and are "minor", in some sense. Jack> ... but with Python 2.3 we have the situation that the majority of Jack> Python installations (I think it's safe to take the guess that Jack> MacOSX 10.3 installations will soon outnumber all other Pythons Jack> together) will stay at 2.3 until the next release of MacOSX. I wouldn't be so sure of that. Aside from the many Linux distributions which include some version of Python, it's clear that HP/Compaq is including some version of Python with their new Windows computers (based on all the newbie questions about this fielded at webmaster@python.org). Still, the number of vendors delivering Python with their computers and the long string of problems caused by RedHat shipping Python 1.5.2 w/ 7.x long after 2.0 was history suggests that micro releases be reserved entirely for bug fixes. Skip
On Monday 08 September 2003 01:04, Skip Montanaro wrote:
"Jack" == Jack Jansen <Jack.Jansen@cwi.nl> writes:
Jack> ... but with Python 2.3 we have the situation that the majority of Jack> Python installations (I think it's safe to take the guess that Jack> MacOSX 10.3 installations will soon outnumber all other Pythons Jack> together) will stay at 2.3 until the next release of MacOSX.
I wouldn't be so sure of that. Aside from the many Linux distributions which include some version of Python, it's clear that HP/Compaq is including some version of Python with their new Windows computers (based on all the newbie questions about this fielded at webmaster@python.org). Still, the number of vendors delivering Python with their computers and the long string of problems caused by RedHat shipping Python 1.5.2 w/ 7.x long after 2.0 was history suggests that micro releases be reserved entirely for bug fixes.
Seconded, from where I'm sitting MaxOSX is not even on the radar, but Linux is all over the place, on various platforms, and all those we use have Python out of the box. RedHat on Itanium still seems to have 1.5.2 for instance. Mandrake 9.1 is on 2.2.2. Mandrake 9.2 will have Python 2.3. Personally I would have guessed there to be more Mandrake Linux installations than MacOSX installations - but in reality I have no idea. Just a datapoint... Harri
Jack> ... but with Python 2.3 we have the situation that the majority of Jack> Python installations (I think it's safe to take the guess that Jack> MacOSX 10.3 installations will soon outnumber all other Pythons Jack> together) will stay at 2.3 until the next release of MacOSX.
[Skip]
I wouldn't be so sure of that. Aside from the many Linux distributions which include some version of Python, it's clear that HP/Compaq is including some version of Python with their new Windows computers (based on all the newbie questions about this fielded at webmaster@python.org). Still, the number of vendors delivering Python with their computers and the long string of problems caused by RedHat shipping Python 1.5.2 w/ 7.x long after 2.0 was history suggests that micro releases be reserved entirely for bug fixes.
I agree with Jack & Just that MacOSX is a strong argument for keeping new features, no matter how harmless, out of micro releases. But I'm not sure how Red Hat shipping 1.5.2 proves this point; there were no micro releases of 1.5 after that. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> But I'm not sure how Red Hat shipping 1.5.2 proves this point; Guido> there were no micro releases of 1.5 after that. True, but it demonstrates how much agony changes to the language - regardless of the versioning - can cause. Skip
Guido> But I'm not sure how Red Hat shipping 1.5.2 proves this point; Guido> there were no micro releases of 1.5 after that.
True, but it demonstrates how much agony changes to the language - regardless of the versioning - can cause.
Skip
Then that's an argument against changes to the language in general. We've had that argument, and the resulting policy is specified in PEPs 4 and 5 (amongst others). --Guido van Rossum (home page: http://www.python.org/~guido/)
>> True, but it demonstrates how much agony changes to the language - >> regardless of the versioning - can cause. Guido> Then that's an argument against changes to the language in Guido> general. We've had that argument, and the resulting policy is Guido> specified in PEPs 4 and 5 (amongst others). I wasn't trying to suggest the language shouldn't evolve, just that ... Oh, never mind. I'm sure you actually know what I meant. S
Maintenance branches are for bug fixes <em>only</em>;
This question is heavily debated. Alex Martelli, for example, favours a policy where new (in a strict sense) features are acceptable if they don't break anything, and are "minor", in some sense.
Which pretty much matches the policy I used informally before all this was written down in PEPs. (Admittedly, 1.5.2 went way beyond this, and I don't wish to go back to those days.)
maintaining backwards compatibility at every level is imperative. (In particular, all extension modules and bytecode for Python 2.<em>x</em>.<em>y</em> must continue to work with Python 2.<em>x</em>.<em>y+1</em> -- binary compatibility in the C API and bytecode must be maintained.)</p>
Even that requirement got dropped at one time, on grounds of the specific API being irrelevant for all practical applications.
So the rule becomes all extension modules and bytecode "in actual use" must continue to work. BTW I don't think we've ever changed the bytecode in a micro release after 1.5.2, and I want to continue to be strict about that.
<p>Any Python developer may checkin bug fixes on a maintenance branch; it is the release manager's responsibility to create the maintenance branch after releasing a new major Python version.</p>
The typical guidelines apply: If in doubt, post to SF.
Or discuss it here. (I personally don't see new bugs on SF, but I do read all of python-dev -- though this should come as no surprise, as according to Brett's stats, I also write most of it. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sun, 2003-09-07 at 12:19, Greg Ward wrote:
<h5>Release branches</h5>
<p>Every release up to and including the final release for a new major Python version is accompanied by a <em>release branches</em>.
There's even some debate about these (I've caught up with the thread, so I know you've withdrawn this change). I've been backing off the use of release branches because they create more complexity in a world where none of us have much time to deal with it. For 2.3, python-dev was really good about heeding calls for checkin freezes, and the time between wanting to cut the release and actually doing it was pretty short, so I don't see much need for release branches. I updated PEP 101 to reflect this. -Barry
On 8-sep-03, at 15:18, Barry Warsaw wrote:
<p>Every release up to and including the final release for a new major Python version is accompanied by a <em>release branches</em>.
There's even some debate about these (I've caught up with the thread, so I know you've withdrawn this change). I've been backing off the use of release branches because they create more complexity in a world where none of us have much time to deal with it.
They served me well for the MacPython-OS9 releases. But as 2.3 is going to be the last of those anyway I could live without them, I guess. Although: they'd still be useful in case of unforeseen problems with a distribution that are not code-related. Think of things like the Windows installer turning out to be broken on certain machine, so you want to build the installer again (but not Python itself). -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
On Tue, 2003-09-09 at 05:26, Jack Jansen wrote:
On 8-sep-03, at 15:18, Barry Warsaw wrote:
<p>Every release up to and including the final release for a new major Python version is accompanied by a <em>release branches</em>.
There's even some debate about these (I've caught up with the thread, so I know you've withdrawn this change). I've been backing off the use of release branches because they create more complexity in a world where none of us have much time to deal with it.
They served me well for the MacPython-OS9 releases. But as 2.3 is going to be the last of those anyway I could live without them, I guess.
Although: they'd still be useful in case of unforeseen problems with a distribution that are not code-related. Think of things like the Windows installer turning out to be broken on certain machine, so you want to build the installer again (but not Python itself).
That's a good point. Release branches are probably overkill for alpha/beta/rc releases, but probably make sense for final releases. We actually did create one for 2.3, but I screwed up when I named it and that caused a tiny bit of pain in moving to the maintenance branch. OTOH, for a final release, maybe release branch == maintenance branch. -Barry
Barry Warsaw writes:
That's a good point. Release branches are probably overkill for alpha/beta/rc releases, but probably make sense for final releases. We actually did create one for 2.3, but I screwed up when I named it and that caused a tiny bit of pain in moving to the maintenance branch. OTOH, for a final release, maybe release branch == maintenance branch.
I think that's sufficient. There's no need for them to be separate. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
On 09 September 2003, Barry Warsaw said:
That's a good point. Release branches are probably overkill for alpha/beta/rc releases, but probably make sense for final releases. We actually did create one for 2.3, but I screwed up when I named it and that caused a tiny bit of pain in moving to the maintenance branch. OTOH, for a final release, maybe release branch == maintenance branch.
Well, if nothing else this thread has demonstrated that I'm *not* the only one who's a little confused by the release/maintenance branching policy. *phew*! Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ Just because you're paranoid doesn't mean they *aren't* out to get you.
participants (17)
-
Alex Martelli -
Anthony Baxter -
Barry Warsaw -
David Eppstein -
Fred L. Drake, Jr. -
Greg Ward -
Guido van Rossum -
Harri Pasanen -
Jack Jansen -
Just van Rossum -
martin＠v.loewis.de -
Matthew F. Barnes -
Phillip J. Eby -
Raymond Hettinger -
Skip Montanaro -
Steve Holden -
Tim Peters