cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radhika Puthiyetath <>
Subject RE: [DISCUSS] releases going forward
Date Thu, 08 Nov 2012 05:28:32 GMT
>From the documentation perspective 

+1 for 4-6 months for major release, and 2-3 months for patch/maintenance release

-----Original Message-----
From: Rohit Yadav [] 
Sent: Thursday, November 08, 2012 10:53 AM
Cc: Alex Huang; Childers
Subject: Re: [DISCUSS] releases going forward

On 08-Nov-2012, at 5:52 AM, Caleb Call <> wrote:

> From a non-developer perspective, more releases shows a project is actively being worked-on/improved.
 We I'm looking at new projects to fill needs, that's definitely something I look at.

Yes, but if we ignore the frequently released browsers who've reached some major version like
24.x (chrome), 16.x (for mozilla) and who knows by the time you read this email they might
have released one more :) A CloudStack user may not want to upgrade every week or month but
can do quarterly or half yearly release upgrades.

Alex, Chip; May we can do major releases every 4-6 months and do maintenance/bugfix releases
every 2-3 months?


> Thanks
> On Nov 7, 2012, at 4:42 PM, Alex Huang <> wrote:
>> +1 semver
>> +1 on 4 months as the timing.  My opinion is that the more releases we'll do, the
better we'll get at it. 
>> --Alex
>> -----Original Message-----
>> From: Marcus Sorensen []
>> Sent: Tuesday, November 06, 2012 11:25 PM
>> To:
>> Subject: Re: [DISCUSS] releases going forward
>> 4 months seems like plenty when I consider the things that missed the cut into 4.0.
 I'm not sure how much the cycle will drive/kick off new development vs just opening a window
to merge changes that may have been incubating any number of months, or just not lined up
perfectly with the previous window.
>> On Nov 5, 2012 2:41 PM, "David Nalley" <> wrote:
>>> On Mon, Nov 5, 2012 at 12:58 PM, Joe Brockmeier <> wrote:
>>>> On Mon, Nov 05, 2012 at 06:34:35AM -0800, Kevin Kluge wrote:
>>>>> 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.
>>>> Presumably, releases will be less work once we do them a few times 
>>>> and keep adding automation.
>>>> I'm not really picky about 6-month vs. 4-month, but I just wanted 
>>>> to point out that future releases should be easier than this one.
>>> Six months seems like an eternity to me, though Kevin's point re 
>>> level of effort is worth acknowledging. Look at the past history of 
>>> changes within 6 month windows - they've been massive - if anything 
>>> this increases the QA burden at the end of a large development 
>>> cycle, there is greater surface area in which changes happen. I 
>>> personally favor release frequently and release often with smaller changesets.
>>> Honestly the focus of the 4.0 release was largely getting the 
>>> codebase into shape from an ASF policy POV - but that doesn't 
>>> diminish the massive number of man hours invested into manually 
>>> testing. IMO that's not repeatable nor should we strive to make it 
>>> routinely repeatable at that scale. We were fortunate that the 
>>> Citrix QA folks essentially carved out man-weeks worth of time for 
>>> us, but we can't guarantee that they will equally be available to 
>>> us, nor should the project be dependent on them. We simply have to 
>>> have automated testing that runs continuously and thoroughly. The 
>>> code base is too large and even to people who have been hacking on 
>>> it for years, it's depths are occasionally unfathomable.
>>>>> 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.  >
>>>> Not sure I understand the distinction you're making here.
>>>> In another thread, I think we were discussing monthly releases for 
>>>> minor releases. IMHO, that's a good schedule and we should try for 
>>>> a monthly release rather than trying to decide each one independently. (e.g.
>>>> "well, do we have enough bugfixes for a point release now? How 
>>>> about now?" Etc.)
>>> I think this is far more subjective. You don't issue a bugfix 
>>> release if there are no bugs to fix (unlikely that there will be no 
>>> bugs, but there might be no bugs that are worth fixing, or that 
>>> people have
>>> fixed) or alternatively we may discover a bug awful enough to demand 
>>> a faster release and only releasing on 'patch Tuesday' isn't in 
>>> everyone's best interest.
>>> --David

View raw message