Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sudha.ponnaganti@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Sudha Ponnaganti <sudha.ponnaganti@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Mon, 5 Nov 2012 07:24:46 -0800
Subject: RE: [DISCUSS] releases going forward
Thread-Topic: [DISCUSS] releases going forward
Thread-Index: Ac23zKifGb8tc7wWQrWBA4KmirkhYADlao2gAAHWxbA=
Message-ID: 
 <7914B38A4445B34AA16EB9F1352942F1012F11C94510@SJCPMAILBOX01.citrite.net>
References: 
 <CAKprHVYjby-15N_ecDR8+AELueT2uRb1ouZjvSPFvcTV1S4=eA@mail.gmail.com>
	<4FB26147.1060307@suse.com>
	<CAKprHVYJZNwwfrixOJBvmoZNB+xTtakTk79e5Rw8YvVXEEbDBA@mail.gmail.com>
	<60E64BEC-7367-4E72-95C7-DB319D3DB592@stratosec.co>
	<4FB65E06.5070109@suse.com>
	<CAKprHVZPZjAhKHObdA-MMLJGt2QAh=QgKdBRcyaNJKxo7mrfKA@mail.gmail.com>
	<CA+96GG5Mitx=1UgHsu5Zv9jxtpLxXT1MvE4C4QNtpX8tUAaUGA@mail.gmail.com>
 <CALFpzo7DSv-4TuH=SLd135tVHFSSmCsVOQpTFN3FByjA=pdbJA@mail.gmail.com>
 <61AE1E2837A06D4A8E98B796183842D40129337A102B@SJCPMAILBOX01.citrite.net>
In-Reply-To: 
 <61AE1E2837A06D4A8E98B796183842D40129337A102B@SJCPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

+1

-----Original Message-----
From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]=20
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 thin=
king of something like Fedora.  We can independently decide to do minor rel=
eases (presumably no features) in between the majors.

-kevin

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