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

Christopher Petrilli petrilli@amber.org
Mon, 08 Apr 2002 20:57:39 -0400

On 4/8/02 8:47 PM, "Guido van Rossum" <guido@python.org> wrote:

In the FreeBSD world (where I also participate), there is no such thing as an "experimental" release, such as the linux world might have. All "RELEASES" are stable, by definition. That's part of why it moves slower. That's what I like to believe of Python's "final" releases, too.

This is something I'd like to keep going, and something the numbering "scheme" would undermine. I trust that if it's "released" it's stable, regardless of whether it's compatible with what I'm doing.

There was just an announcement of a "Developer Preview" of 5.0, which is still 6 months away most likely. It is however, kept separate from the standard releases. This is the warning that accompanied the announcement:

***************************** WARNING ******************************** This is a development snapshot, and may include serious software bugs. Do not install this on a machine where important data may be put at risk. In addition, a number of debugging options are turned on by default, so the poor performance of this snapshot should not set expectations for the final release of 5.0. ********************************************************************** How is this different from an alpha or beta release?

As long as I've been in the FreeBSD world, I've never seen an alpha/beta release. What you get are the occasional Developer Preview (I think there is usually one before each X release (in X.Y). Then there are release candidates, usually 2-3. Otherwise, people are assumed to work off the trees directly, and there are tools to keep your system in check very easily.

I have a machine here (dual Ppro, a bit antiquated, but it serves it's purpose) which CVSups (an automated CVS system) an updated environment every day, then builds the entire thing (which can take hours). It's painless for me, and I get to test some things I'm working on against the bleeding edge with little or no effort.

In the FreeBSD world, you don't shove experimental code that hasn't gone through "some testing" into the CURRENT tree. It may not build everywhere, but it's gone through some testing, and usually will not cause anyone serious pain.

I guess in the end, I see several competing interests here:

- People who want minimal to no backward incompatibilities, ever
- People who want to know that a release will be "supported" for
  some defined period
- People who want the bleeding edge to be more available

I would think that 90% of this can be solved with simple communications of what should be expected. It's not unreasonable to say that 2.1 will be supported with BUG FIXED (not features, bug fixes) until 2.4 or 2.5 is released. If we're on a 6-month "minor release" schedule, then that's roughly a year of stability. That seems generous.

Chris

| Christopher Petrilli | petrilli@amber.org