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

Christopher Petrilli petrilli@amber.org
Mon, 08 Apr 2002 18:46:46 -0400

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