Release schedule plans

[Kevin Benton]

<soapbox>
I thought the whole point of branching was to have a clear-cut line in the
sand where the thought was that it's time to move to the next stage.  If
there are bugs past the branch, then it just helps underscore the need for
high-level QA.  On the other hand, if you wait, it's harder to say - here's
the line.  Let's move on.
</soapbox>

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Gervase Markham
> Sent: Monday, January 10, 2005 3:41 PM
> To: developers at bugzilla.org
> Subject: Re: Release schedule plans
> 
> [Apologies for the lack of threading; I was missing the message and so
> had to cut and paste from the archives.]
> 
> > A quick summary of some of the ideas that were hashed out (but it'll
> > make better sense if you actually read the log a the above URL) :
> >
> > 1) Should we abort the 2.20 freeze and make our March 15 freeze be for
> > 2.20 instead of 2.22?
>  >
>  > This sits at an undecided Maybe from the existing discussion on IRC,
>  > but leaning towards releasing 2.20 in the immediate near future
>  > anyway, thanks to the discussion in point number 5 below.
> 
> It seems that we have three choices:
> 
> a) Release 2.18 and release 2.20 soon afterwards
> b) Release 2.18, unfreeze for a bit, and release 2.20 in (say) June
> c) Abandon 2.18 and just release 2.20
> 
>  From the point of view of our customers, who don't want to upgrade too
> frequently, and from our point of view, where we don't want to have to
> maintain too many branches, a) is the worst case scenario.
> 
> It puts two releases close together, which will affect maintenance and
> release management for at least 18 months. It also means we have a
> confused story. "Upgrade to our shiny new 2.18! It's the first stable
> release for three years! Except unless you can wait another month or
> two, in which case 2.20 is coming right along behind it, and it's
> better." It's like buses. You wait three years for one...
> 
> So IMO we should either unfreeze the trunk and develop some more (which
> seems reasonable; we don't have that many new features yet anyway) or we
> should scrap 2.18 altogether and release 2.20, if it's so close.
> 
> > 2) Should we attempt an "eased transition" into the 6 month cycle where
> > we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 would
> > freeze March 15 as above), then 9 months for 2.22 (making it Jan 1
> > 2006), then 6 months from there on out?
> 
> Remind me again why we are so keen to do a *six* month release cycle?
> What was the rationale there?
> 
> > 4) b.m.o upgrade schedule was discussed.
> 
> <snip>
> 
> I agree with everything that was said, apart from the fact that we
> should upgrade just _before_ we branch rather than just after. That
> means that, if there's more fallout than expected, we don't have to do
> lots of work applying patches to two near-identical branches, and the
> people who would fix the fallout aren't distracted by checking shiny new
> features into the trunk.
> 
> Gerv
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton@amd.com>