4months seems a good time frame. That will allow external projects (jclouds, fuse fabric, ...) to test and update documentation
On Mon, Nov 5, 2012 at 5:47 PM, Rajesh Battala <rajesh.batt...@citrix.com>wrote: > +1 > > -----Original Message----- > From: Kevin Kluge [mailto:kevin.kl...@citrix.com] > Sent: Monday, November 05, 2012 8:05 PM > 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 > > > > > > > > -- Charles Moulliard Apache Committer / Sr. Enterprise Architect (RedHat) Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
