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:06:45 GMT
The release is absolutely 4.0.0-incubating. This thread is an old one,
which I dug up trying to remember if we picked a release timeframe
previously. We had not, as far as I can tell.

- chip

Sent from my iPhone.

On Oct 31, 2012, at 9:28 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:

> Oh, and I vote 4.0 for the first apache release. Unless I totally
> misunderstand something that's what we've been calling it for awhile and I
> think it will confuse things for outsiders to change now.
> On Oct 31, 2012 7:16 PM, "Marcus Sorensen" <shadowsor@gmail.com> wrote:
>
>> I just reread this, and it sounds more like we decide what the version
>> will be (major or minor) AFTER we know what's going into it. I'm OK with
>> that of course, but we'll need some sort of definition to go by. I also
>> think it may end up in favor of major revs more often than not.
>>
>> We could also do something else like align major revs with target
>> platforms, e.g. 4.0 targets centos 6.x and Ubuntu 12.04, with minor revs
>> being feature releases. That may help solidify the support life cycle as
>> well, and we just rev when the next generation of platforms is chosen and
>> tested.
>> On Oct 31, 2012 7:02 PM, "Marcus Sorensen" <shadowsor@gmail.com> wrote:
>>
>>> +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