[Python-Dev] Re: Stability and change

[Christopher Petrilli]

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