Hi Erik, Kishan, Since the goal is a stable master, I’d say the bug fix should go to master first. This way we make sure all upcoming releases have the fix included. I’ll add this to the wiki.
Then we should decide if the fix should go back to other release branches as wel. When we get a PR that is not against master, we should be extra careful. Maybe we should ask people to specify why they want to do this. There could be a valid reason, of course. The danger is introducing old bugs again if people upgrade and I want to prevent that. In Erik’s example: The first PR is against master and fixes SomeRandomFunction(). Now we know any release branched off master has this fix. If we decide we want to fix 4.6 as well, a second PR should be created against 4.6 (reimplementation of the fix to older version as per Erik's example). In a perfect world we should be able to merge back from 4.6 to master. But for example i case of refactoring this is not possible. Regards, Remi > On 2 jul. 2015, at 14:05, Erik Weber <terbol...@gmail.com> wrote: > > How about bugfix PRs that involves refactored code between versions? > > Example: > > - 4.6.0 is released > - SomeRandomFunction() is refactored > - 4.7.0 is released > - A bug is discovered in SomeRandomFunction() and applies to both 4.6.0 > and 4.7.0 > - A bugfix PR is sent to the 4.6 branch > > I understand that the code has to be ported to both versions, but how do we > ensure/enforce that it actually happens? > > -- > > Erik > > On Thu, Jul 2, 2015 at 2:03 PM, Kishan Kavala <kishan.kav...@citrix.com> > wrote: > >> Remi, >> Release process looks good to me. Can you also add some info about >> maintenance release? >> - After release, will the fixes go into x.y branch and merged back to >> master? >> - or bug fixes go into master and selectively merged back to x.y branch? >> >> >> -----Original Message----- >> From: Remi Bergsma [mailto:r...@remi.nl] >> Sent: 02 July 2015 17:17 >> To: <dev@cloudstack.apache.org> >> Subject: [DISCUSS] Release principles for Apache CloudStack >> >> Hi all, >> >> We already agreed contributions should always go via a PR and require two >> LGTM’s before we merge. Let me propose the next step on how I think we >> should do release management for 4.6 and on. >> >> I talked to several people over the past weeks and wrote this wiki article: >> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack >> < >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack >>> >> >> If you like this way of working, I volunteer to be your RM :-) >> >> Like folks suggested earlier, it would be nice to work on this with >> multiple people. So, feel free to join. Maybe @dahn @bhaisaab and/or others >> are willing to teach me some of their tricks. >> >> Regards, >> Remi >> >>
