> -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Thursday, July 05, 2012 12:02 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: ASF repo tags > > > How about this, just to define it (more or less what David just said): > > * For development/feature branches, the developer(s) have a > responsibility of making sure their code will cleanly merge back into master, > either by keeping their branch in sync with master, or by doing any triage at > time of merging their branch back to master when ready. > > * The only time CS patches and releases an update for a release is in the > event of a security vulnerability. If a vulnerability is found, the CS team > will > evaluate releases within the last 3 releases, and issue patches where > necessary. > > * Otherwise, patches will be applied to the master tree only. > > > > I am ok with this in principle. But let me toss another situation and see what > your reaction is. > Let's say we release 5.2.0 on Monday, and on Wednesday, we find an > absolutely horrendous bug that would effect a large number of users. > Would we still wait til 5.3.0 n-months down the road - or release > 5.2.1 in a matter of a week(s)? > > While I don't like the idea of maintaining multiple releases, there are > occasions where it could make sense.
I agree, in that case we'd have to release a 5.2.1, otherwise the users will go somewhere else. I assume whoever was release manager for the 5.2.0 release would own the subsequent maintenance releases -- including deciding whether or not there is one, and what goes in if there is one. I'm unclear on who would be expected to merge a given fix from master into the 5.2.x branch. Perhaps the release manager should create a ticket then assign it to whoever committed the original patch? So by committing a patch you agree to subsequently merge it into other branches if asked to do so by a release manager in the project. -kevin
