That's cool. The times involved were much less important than the general structure of the proposal. (And it is just that, a proposal. If y'all can think of better ways to do this, I am excited to hear them. This is an area I'm trying to figure out myself.)
On 5 November 2012 14:39, Kevin Kluge <kevin.kl...@citrix.com> wrote: > 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.child...@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 <nsla...@apache.org> wrote: > > > > > On 2 November 2012 03:07, Chip Childers <chip.child...@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 > -- NS
