incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajesh Battala <rajesh.batt...@citrix.com>
Subject RE: [ASFCS41] Proposed schedule for our next release
Date Mon, 05 Nov 2012 16:08:17 GMT
+1.
It would be good if we have 4 month cycle of release. It will give developers, QA and doc
to deliver quality code. 

Thanks
Rajesh Battala

-----Original Message-----
From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com] 
Sent: Monday, November 05, 2012 8:10 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [ASFCS41] Proposed schedule for our next release

This schedule gives us only 7 weeks from today to develop features, and of that time most
committers will be offline for a week or two due to holidays.  Some features have already
been developed, but I don't think, relatively speaking, much has been done in the past few
weeks.  Even if we adopt 4 month release cycles (as in the other thread) we'd still get 4
months of feature development, unlike this proposal where dev time is quite small.   I'd prefer
to push this release to have at least 4 months of dev.  This better spreads out the cost of
regression testing, doc reviews, etc and be more efficient for the project.  So I'd propose
to take the dates you listed and add two months to all of them.

-kevin


> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Saturday, November 03, 2012 9:32 AM
> To: <cloudstack-dev@incubator.apache.org>
> Subject: Re: [ASFCS41] Proposed schedule for our next release
> 
> On Nov 3, 2012, at 12:06 PM, Noah Slater <nslater@apache.org> wrote:
> 
> > On 2 November 2012 03:07, Chip Childers <chip.childers@sungard.com>
> wrote:
> >
> >> First, note the subject tag of "[ASFCS41]".  I'm making 2 
> >> assumptions right now.  First, that we should adopt semantic 
> >> versioning for our versioning scheme.  Second, that our next 
> >> feature release will be backward compatible with 4.0.0-incubating.
> >
> > Cool. Which would make it 5.0, then?
> >
> 
> Nope, 4.1.0. Key statement: "will be"
> 
> >
> >> * Developers, does a 2 month window to get new stuff into a master 
> >> for the feature release work?  Do you think that this is enough 
> >> time to deal with the bugs that come out of testing?
> >
> >
> > You might want to consider striping your releases, so you do a 
> > feature release, then two bug fix releases.
> >
> Yup, thats what we have been discussing. I'm only talking about the 
> feature release in this thread.
> 
> > Consult the following WIP for more of an idea of what I mean:
> >
> > http://wiki.apache.org/couchdb/Roadmap_Process
> >
> > Quoted from that page (which has diagrams, so you're missing out):
> >
> > Feature
> >
> >
> >
> > Every three months, we will release a new feature release.
> >
> >
> >
> > These releases will contain any new features in them since the last
> >> release, as well as any bugfixes.
> >
> >
> >
> > If the release contains breaking changes, it will be a major 
> > release, else
> >> it will be a minor release.
> >
> >
> >
> > Each feature release will be supported for 12 months.
> >
> >
> >
> > Therefor, at any one particular time, there should be four supported
> >> feature releases.
> >
> >
> >
> > Bugfix
> >
> >
> >
> > Every month in-between the feature releases, we will release bugfix
> >> releases.
> >
> >
> >
> > We will do a bugfix release for any supported feature releases, 
> > where
> >> bugfixes are available.
> >
> >
> >
> > This may involve backporting the bugfix to four supported feature releases.
> >
> >
> > Just an idea at this stage, even for CouchDB.
> >
> > But would be interested in hearing how you think it might work for us, here?
> >
> >
> > --
> > NS

Mime
View raw message