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 > >
