cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: [DISCUSS] 4.6 release management
Date Fri, 17 Apr 2015 19:00:05 GMT
Well, would we just swap the last release branch with master? Master
is the dev branch, and the last release is really what we have as a
stable branch.

On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <> wrote:
> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <> wrote:
>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <> wrote:
>>> Today during the CloudStackdays  we did a round table about Release
>>> management targeting the next 4.6 releases.
>>> Quick bullet point discussions:
>>> ideas to change release planning
>>>   - Plugin contribution is complicated because often  a new plugin involve
>>>   change on the core:
>>>      - ex: storage plugin involve changes on Hypervisor code
>>>   - There is an idea of going on a 2 weeks release model which could
>>>   introduce issue the database schema.
>>>   - Database schema version should be different then the application
>>>   version.
>>>   - There is a will to enforce git workflow in 4.6  and trigger simulator
>>>   job on  PullRequest.
>>>   - Some people (I'm part of them) are concerned on our current way of
>>>   supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>   4.5.x). But the current level of confidence against latest release is low,
>>>   so that need to be improved.
>>> So, the main messages is that w'd like to improve the release velocity, and
>>> release branch stability.  so we would like to propose few change in the
>>> way we would add code to the 4.6 branch as follow:
>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>> which would trigger a simulator job, ideally only if that pass the PR would
>>> be accepted and automatically merged.  At this time, I think we pretty much
>>> have everything in place to do that. At a first step we would use
>>> simulator+marvin jobs then improve tests coverage from there.
>> +1
>> We do need to realize what this means and be all fine with it.
>> It means that if someone who is not RM directly commits to the release branch, the
commit will be reverted.
>> And that from the beginning of the branching…
> I agree and we can even go as far as reverting fixes that are
> cherry-picked in favour of merged forward.
>> IMHO, I think this would be a good step but I don’t think it goes far enough.
> Agreed here as well but let's take the step while discussing further
> steps and not implement to much process as well
>> This still uses a paradigm where a release is made from a release branch that was
started from an unstable development branch.
>> Hence you still need *extensive* QA.
> The problem here is that there is no stable point to fork from at the
> moment. We will get there and we shouldn't stop taking steps in that
> direction.
>> If we truly want to release faster, we need to release from the same QA’d branch
time after time….a release needs to be based on a previous release
>> Basically, we need a rolling release cycle. That will have the added benefit to not
leave releases behind and have to focus on backporting.
>>> Please comments :-)
> --
> Daan

View raw message