[Python-Dev] Re: Stability and change

[Christopher Petrilli]

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