incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: [DISCUSS] releases going forward
Date Thu, 01 Nov 2012 01:28:13 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message