[Python-Dev] Re: Stability and change

[Christopher Petrilli]

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

> 
>   BAW> Okay, so now I tell have to tell people that it works with any
>   BAW> version between 2.4.3 and 2.6.9, not including any 2.5.x release.
> 
> Over time people should become aware that odd-numbered minor releases are
> always development releases and are not to be relied upon.  Sure, you can't
> say it works for 2.4.3 through 2.6.9 but you can say
> 
>   It works for 2.4.x for x >= 3 and for 2.6.x for x <= 9.
> 
> And during the initial three years of turmoil after a change to such a dual
> branch structure is made you'd probably be wise to add
> 
>   No support for any development branch releases (e.g. 2.N.x, where N is
>   odd) is implied.

What Barry is trying to say, and I most certainly agree with his most
rockiness, is that there shouldn't be oral tradition, it should be obvious,
on first inspection.  Just because some percentage of the planet that uses
Linux understands this numbering scheme (and I'd bet that only 20-30% of the
Linux users actually do),doesn't mean it's fare to assume all users would at
first blush.

The double-branch option is easier, and I know that when the FreeBSD group
releases 4.5-RELEASE, it's been tested and solid, and will be supported by
bug fixes for some period of time.  They have only just recently stopped
issue security patches for the 2.x tree.

Someone asked how long someone should assume "stability" of a release, or at
least viability of a release, and I would say that 2 release cycles is a
good number.  In other words, if you're on 2.2, when 2.5 comes out, you
won't get any more patches or support.

One thought that has been in my mind for years, as Guido knows (I whined
about it in the 1.3->1.4->1.5 days) is that we are overly conservative in
our "major" release information.  Perhaps we would be better served from a
PR perspective (because in the end, that's all we're talking about) if we
were to make 1 "major" release per year, and some minor number after that.
That minor number wouldn't exceed 3-4, but there would be some guarantee
that within that "major" train, all things were compatible.

It's just an idea, but I'm really opposed to magic numbers in determining
whether something is a stable or experimental release.  We might as well say
that only those releases that are prime numbers are in fact stable.  That
would give us the distinct advantage of longer and longer cycles as we make
releases :-)

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org