incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] releases going forward
Date Thu, 01 Nov 2012 03:05:36 GMT
4.0.0 was hard, because we couldn't just say "well, these are the
fixes we did on the legal front that made it in."  It was an all or
nothing proposition, which was the primary struggle.

As long as we keep ourselves in legal order, we limit future releases
to the feature inclusion/exclusion question. That is easier to deal
with IMO.

- chip

Sent from my iPhone.

On Oct 31, 2012, at 10:54 PM, Will Chan <will.chan@citrix.com> wrote:

> +1
>
> I would love to make sure that we are strict on the time-based release.  I know that
I would love to continue to add more and more features on each release and I'm sure Citrix
would love to incoporate features for their commercial releases but if we are not strict with
this, we will just keep slipping.  Other than that, I am in favor of this.
>
> Will
>
> ________________________________________
> From: Marcus Sorensen [shadowsor@gmail.com]
> Sent: Wednesday, October 31, 2012 6:02 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] releases going forward
>
> +1, this would line up nicely with having a major rev once a year with 2 or
> 3 minor revisions in between.
> Then maybe once a month someone rolls up any applicable bugfixes and we do
> a point release? Do we want to have some procedure around that, like a mini
> vote?
> On Oct 31, 2012 6:26 PM, "Chip Childers" <chip.childers@sungard.com> wrote:
>
>> On Thu, May 24, 2012 at 10:45 AM, David Nalley <david@gnsa.us> wrote:
>>> So I think we have consensus around a few things already - lets
>>> highlight those:
>>>
>>> * Time based releases
>>> * Versioning scheme:
>>> X.Y.Z
>>>
>>> - X : increases when there is a "major" change in architecture or some
>>> major new feature
>>> - Y : increases with every release every 6 month (reset when X increases)
>>> - Z : increases when there are "must fix bugs" or annoying bugs that
>>> get fixed in a release branch (reset when Y increases)
>>>
>>>
>>> ===== What we don't yet have consensus on =====
>>>
>>> * What the time period is on releases
>>
>> Digging this out of the past, IIRC, we never got around to resolving
>> the time period for releases.  We should come to a conclusion on this
>> topic!  I'd like to propose that we follow a 4 month release cycle for
>> non-bug fix releases.
>>
>> Generally, it would mean a schedule that would look something like
>> this (M=Month and W=Week):
>> M1 through M2 - Features are being developed in branches, and merged
>> 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 until
>> an RC is voted to be released
>>
>> This proposal might lean a bit heavily towards documentation and
>> testing, but my opinion is that features are going to be developed
>> outside of this release cycle.  What matters, is when they land in
>> master, and when they are scheduled to be released.  IMO, this type of
>> schedule provides us with the ability to have predictable periods of
>> time for stabilization and documentation.
>>
>> If the actual time period of the release is something other than 4
>> months, then I would argue for a similar schedule in the ramp up to
>> the first RC.
>>
>> If we can reach a consensus on this, I'll be happy to draft up a
>> 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 (to
>>> be fair we haven't really discussed this.)
>>>
>>> So lets start with the easy one, the version number - should we target
>>> 3.1.0 or 4.0.0 or something else entirely? I could be swayed either
>>> way.
>>>
>>> On the release time period - as a packager for 20-30 packages in
>>> Fedora I am certainly sympathetic to release cycles, and realize that
>>> virtually all of the community distros (save Debian which is on a two
>>> year release cycle) are on a 6 month cycle. That said I don't know
>>> that we can necessarily be married to what the distros are doing. I
>>> also look at projects like subversion which are tossing out releases
>>> approximately every 60 days - and I don't see any distro that doesn't
>>> carry subversion (though admittedly very different projects in
>>> virtually every respect) I think every 3-4 months makes sense to me,
>>> but again that's just me - gives us a slightly faster iteration but
>>> hopefully not removing towards an unmanageable release cycle speed.
>>>
>>> Another question is - how long do we support any given release
>>> line......e.g. if I embark on 5.2.0 (completely made up version
>>> number, but assuming the above version scheme) how long will I be
>>> guaranteed bugfixes for 5.2.x. Perhaps it's too soon to even ask that
>>> question - we haven't even pushed a single release out, but something
>>> to think about.
>>>
>>> Thoughts, comments, flames?
>>>
>>> --David
>>

Mime
View raw message