Have they diverged that much? Due to cherry-picking, I guess. Otherwise you should be able to do it cleanly.
There's a good opportunity to do this next release. Instead of creating a release branch, we freeze master and start creating dev branches. On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > We heavily invested in code now on master. Not looking forward to > backporting that. > > mobile dev with bilingual spelling checker used (read at your own risk) > Op 17 apr. 2015 21:02 schreef "Marcus" <shadow...@gmail.com>: > >> 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 <daan.hoogl...@gmail.com> >> wrote: >> > On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <run...@gmail.com> >> wrote: >> >> >> >>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com> >> 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 >>
