incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [ASFCS41] Proposed schedule for our next release
Date Thu, 15 Nov 2012 17:46:20 GMT
On Thu, Nov 15, 2012 at 12:34 PM, Rohit Yadav <> wrote:
> +1 I'm fine with the proposed schedule as well, but few of my questions were not answered,
if they're worth answering:
> 1. Number of maintenance or bug-fix releases on 4.0.x, 4.1.x etc. and the duration, timeline
of the same?
> 2. Frequency of these rather short term bug-fix releases?
> 3. Are we going to do a LTS, say for a year or two?
> 4. Will we have branch/version maintainers, since as per proposed schedule we will have
3-4 branches by the end of next year? I'm happy to have Joe doing 4.0.x (does this mean he's
the 4.0 maintainer?) and Chip helping us out once again with 4.1.

Purely IMO:

I'd consider major version support to be the main question here.  To
me, our release calendar is fast enough that we can keep bug fix
releases limited to critical bugs and security fixes.  I'd also
propose that we don't support 4.0.x bug fix releases after 4.1.0 is
released.  Instead, we shift to supporting 4.1.x bug fix releases
until 4.2.0.  And then the same thing happens.  The value of semver is
that the product can keep growing, but that the API remains
compatible.  Hence, I would push users to upgrade to the latest
feature release of the major version line they are using for newer

Things change when we talk about the 4.x.x series support when we
eventually go to 5.0.0.  IMO, we do need to continue to do the same
critical bug fixes and security patches as needed, for some number of
years.  I'd suggest that it's somewhere in the neighborhood of 2 years
after the new major version is introduced.  Does that sound right to

As for branch/version maintainers, I'm not sure.  We certainly need to
have folks (thanks Joe!) managing bug-fix releases and doing the
cherry-picking.  We may need to make it a community effort to deal
with any issues merging a fix into an older version though.


> Regards.
> ________________________________________
> From: Chip Childers []
> Sent: Thursday, November 15, 2012 10:53 PM
> To:
> Subject: Re: [ASFCS41] Proposed schedule for our next release
> On Mon, Nov 12, 2012 at 4:28 PM, Chip Childers
> <> wrote:
>> Taking everyone's input into consideration, I've reworked the proposed
>> schedule (below).  I've extended the feature dev period until the end
>> of Jan, giving us a 5 month (3 for features, 2 for testing / wrap-up)
>> schedule for this next release.
>> Does this sound like something we can all get behind?  Did I miss any
>> significant issues raised in this or other threads?
>> If the 4.1 schedule proposal works, I'd further propose that we shift
>> to a 4 month schedule for feature releases afterward. IMO, we should
>> be basically developing features outside of a release, and bringing
>> them into master when the window is open for inclusion in the next
>> release.  This gives any developer as much time as they would like
>> (although the longer it goes on, the harder it is to potentially
>> integrate back into master), and the community gets a clear view of
>> what our "time-based" release schedule will look like.
>> This rhythm would set us up with the following high level dates:
>> ================================
>> Proposed schedule for ongoing releases
>> ================================
>> 4.1
>>   Nov through Jan - Feature work
>>   Feb and March - Testing / Hardening / Wrap-up
>> 4.2
>>   April and May - Feature work
>>   June and July - Testing / Hardening / Wrap-up
>> 4.3
>>   August and September - Feature work
>>   October and November - Testing / Hardening / Wrap-up
>> 4.4
>>   Start all over in Dec
>> ** This assumes no major version increments, but we could certainly have one!
>> =============================
>> New 4.1 detailed schedule proposal:
>> =============================
>> 2012-11-01 through 2013-01-31
>>   Feature and documentation development (obviously ongoing, but
>> continued during this period)
>> 2013-01-31
>>   Feature Freeze
>>   All new feature need to have been merged into master by this date.
>>   Release branch will be cut on this date.
>>   Jenkins updated to include new release branch builds.
>> 2013-02-01 through 2013-02-28
>>   Testing/Bug Fixes (testing against jenkins artifacts)
>>   Documentation Finalization
>> 2013-02-28
>>   Docs Freeze (except release notes and translations)
>>   Release Branch moves to limited updates only (only commits allowed
>> in would be release blockers fixes, translation updates, etc...)
>> 2013-03-01 through 2013-03-22
>>   Translation Development and Integration (should be ongoing, but
>> focused effort)
>>   Final regression testing / bug fixes / doc fixes
>> 2013-03-22
>>   4.1.0-RC1 is created, and project level VOTE is called
> Having only heard back from David and Joe on the revised proposal
> above, I'm going to assume that we're agreeing under a lazy consensus
> process here.
> Also, I'll throw my hat into the ring to release manage 4.1.0 (while
> Joe is doing the 4.0.x releases).  I'm happy to step aside for anyone
> else that may want to do it this time around, but also more than
> willing to take this next feature release on.  Please shout if you
> have an interest yourself!
> -chip

View raw message