Subject: Re: Release cycles (Was: Re: RealAudio)
To: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: current-users
Date: 11/01/1997 15:06:19
"Michael C. Richardson" <mcr@sandelman.ottawa.on.ca> writes:

>>>>> "Todd" == Todd Vierling <tv@pobox.com> writes:
    Todd> However, it shouldn't be nearly so bad to make periodic
    Todd> subreleases (1.3.1, 1.3.2, ...) on the way to 1.4.  And
    Todd> _not_all_architectures_ should be required to be ready when
    Todd> a subrelease cut is made; this is an interim release system.

>  Yes! Please. Let's do this.
>
>  I would further like to see a release date for 1.3.1 *NOW*, as well
>as a "goals for 1.4" now as well. Maybe a 1.3.2 date.

>  I would propose that 1.3.1 get frozen February 1st, and released two
>weeks later.
 

There is no way to even build and ship out and test ALPHA releases of
a 1.3.1 release in a two-week timeframe.

What you'd get would be something like the 1.2.1 release, where
someone arbitrarily and heavy-handeldy froze and announced a `release'
without consulting the portmasters, without getting fixes in, and
without even ensuring that the fixes that portmasters and developers
had requested for 1.2 *BEFORE* the 1.2 freeze had all got into 1.2.1.
(for various reasons, I think some of them didn't make it.)

Pleas count the weeks between the end of the 1.3 release cycle and
your date. Add at least one week for building final 1.3 sets, and
subtract one week for building 1.3.1 sets.  Count the remaining
weeks. Then subtract out Xmas/thanksgiving/whatever vacations.  And
recuperation time after the 1.3 release cycle.

IMHO, a worthwhile 1.3.1 release in mid-Feburary just isn't realistic,
unless all you expect is a handful of fixes for known bugs.  Which may
not be the same fixes as in -current by then.  Personally, I don't see
how even that little can possibly be adequately tested in your
two-week timeframe.

Heck, I'd like to put that much effort into *snapshots*.


> The other option is to pull a partial Microsoft and dispense with
>the third number. Let's just call the next one 1.4. If we hit 1.9, and
>don't have a 2.0, then we just declare 2.0 anyway.

I think you'e suggesting we do a two-week release cycle and call it
1.4.  Really, no flames, but I sincerely hope I'm misunderstanding you.