[Python-Dev] Re: Stability and change (original) (raw)

Christopher Petrilli petrilli@amber.org
Mon, 08 Apr 2002 19:10:22 -0400

On 4/8/02 7:01 PM, "Skip Montanaro" <skip@pobox.com> wrote:

Chris> The double-branch option is easier, and I know that when the Chris> FreeBSD group releases 4.5-RELEASE, it's been tested and solid, Chris> and will be supported by bug fixes for some period of time. They Chris> have only just recently stopped issue security patches for the Chris> 2.x tree. Is *-RELEASE a third branch, or is it what falls out the end of the *-STABLE pipe?

RELEASE is actually just a tag on the RELENG branch of the tree. For example, FreeBSD has the following branches in CVS for 4.x:

RELENG_4
RELENG_4_3
RELENG_4_4
RELENG_4_5

On those, there are tags for the releases:

RELENG_4_0_0_RELEASE
RELENG_4_1_0_RELEASE
RELENG_4_2_0_RELEASE
RELENG_4_3_0_RELEASE

And so on. This does create a more complex CVS environment than Python uses (and probably similar to what we used at Zope). This is not a bad thing, as it allows you to control things more carefully, but requires more CVS knowledge on the part of people involved.

The following section of the handbook explains in some more detail about how the two branches progress through their life cycle:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.htm l

BTW, as to libraries and /F's comments... I think the library modules should always have to lag at least one release behind the interpreter. Maybe 2? This gives a couple of things:

- No introducing weird problems in the library to compound compatibility
  issues
- Iron out new features/changes by letting those people actually using
  them benefit/feel the pain, before we make the general populace deal.

Again, I think stating what "policy" is about support for older releases is solves a HUGE amount of the problem. And probably a bigger percentage than a numbering scheme ever could.

Chris