>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 [mailto:rohit.ya...@citrix.com]
Sent: Thursday, November 08, 2012 10:53 AM
To: cloudstack-dev@incubator.apache.org
Cc: Alex Huang; chip.child...@sungard.com Childers
Subject: Re: [DISCUSS] releases going forward
On 08-Nov-2012, at 5:52 AM, Caleb Call <calebc...@me.com> 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?
Regards.
>
> Thanks
>
> On Nov 7, 2012, at 4:42 PM, Alex Huang <alex.hu...@citrix.com> 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 [mailto:shadow...@gmail.com]
>> Sent: Tuesday, November 06, 2012 11:25 PM
>> To: cloudstack-dev@incubator.apache.org
>> 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" <da...@gnsa.us> wrote:
>>
>>> On Mon, Nov 5, 2012 at 12:58 PM, Joe Brockmeier <j...@zonker.net> 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
>>>
>
