cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <sudha.ponnaga...@citrix.com>
Subject RE: [DISCUSS] releases going forward
Date Mon, 05 Nov 2012 15:24:46 GMT
+1

-----Original Message-----
From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com] 
Sent: Monday, November 05, 2012 6:35 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] releases going forward

I'd have a preference for 6 month releases.  Releases are a lot of work and I'd prefer to
spread that over fewer iterations per year.

And I would just call them all major releases (versioning aside).  I'm thinking of something
like Fedora.  We can independently decide to do minor releases (presumably no features) in
between the majors.

-kevin

> > Digging this out of the past, IIRC, we never got around to resolving 
> > the time period for releases.  We should come to a conclusion on 
> > this topic!  I'd like to propose that we follow a 4 month release 
> > cycle for non-bug fix releases.
> >
> > Generally, it would mean a schedule that would look something like 
> > this (M=Month and W=Week):
> > M1 through M2 - Features are being developed in branches, and merged 
> > into master over the course of these two months
> > M2 W4 - Feature freeze (and release branch is cut).
> > M3 W1 through M4 W1 - Doc Updates and Testing
> > M4 W1 - Docs Freeze
> > M4 W2 - Final regression testing / bug fixes / doc fixes
> > M4 W3 - First RC cut and opened for voting...  Wash rince repeat 
> > until an RC is voted to be released
> >
> > This proposal might lean a bit heavily towards documentation and 
> > testing, but my opinion is that features are going to be developed 
> > outside of this release cycle.  What matters, is when they land in 
> > master, and when they are scheduled to be released.  IMO, this type 
> > of schedule provides us with the ability to have predictable periods 
> > of time for stabilization and documentation.
> >
> > If the actual time period of the release is something other than 4 
> > months, then I would argue for a similar schedule in the ramp up to 
> > the first RC.
> >
> > If we can reach a consensus on this, I'll be happy to draft up a 
> > schedule with specific dates for our 4.1.0 release.
> >
> > Thoughts, comments, flames?
> >
> > -chip
> >
> > > * What the version number for the first Apache release should be 
> > > (to be fair we haven't really discussed this.)
> > >
> > > So lets start with the easy one, the version number - should we 
> > > target
> > > 3.1.0 or 4.0.0 or something else entirely? I could be swayed 
> > > either way.
> > >
> > > On the release time period - as a packager for 20-30 packages in 
> > > Fedora I am certainly sympathetic to release cycles, and realize 
> > > that virtually all of the community distros (save Debian which is 
> > > on a two year release cycle) are on a 6 month cycle. That said I 
> > > don't know that we can necessarily be married to what the distros 
> > > are doing. I also look at projects like subversion which are 
> > > tossing out releases approximately every 60 days - and I don't see 
> > > any distro that doesn't carry subversion (though admittedly very 
> > > different projects in virtually every respect) I think every 3-4 
> > > months makes sense to me, but again that's just me - gives us a 
> > > slightly faster iteration but hopefully not removing towards an 
> > > unmanageable release cycle
> speed.
> > >
> > > Another question is - how long do we support any given release 
> > > line......e.g. if I embark on 5.2.0 (completely made up version 
> > > number, but assuming the above version scheme) how long will I be 
> > > guaranteed bugfixes for 5.2.x. Perhaps it's too soon to even ask 
> > > that question - we haven't even pushed a single release out, but 
> > > something to think about.
> > >
> > > Thoughts, comments, flames?
> > >
> > > --David
> > >
> >

Mime
View raw message