Yep, that's what I was referring to in that a particular fix for an old release may not apply to newer versions. That does happen.
We used to mark those as "don't need to merge to branch x" in SVN and then you handed it however made sense on the applicable branch(es). On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <stephen.tur...@citrix.com> wrote: > What happens if a fix isn't relevant for newer versions, or has to be > rewritten for newer versions because the code has changed? Don't the > branches diverge and you end up cherry-picking after that? > > -- > Stephen Turner > > > -----Original Message----- > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > Sent: 30 May 2014 18:48 > To: dev@cloudstack.apache.org > Subject: Re: [PROPOSAL] git workflow > > I think this flow is something we should seriously consider. > > I find cherry picking from branch to branch to be error prone in that it's > easy for someone to forget to cherry pick to all applicable branches and > you don't have any easy way to see the cherry picks are related. > > When I worked at HP, we had automated tools check to see if you checked a > fix into a prior release, but not later releases. In such a situation, you > either 1) forgot to perform the check-in or 2) the check-in was no longer > applicable in the later release(s), so you needed to mark it as > un-necessary (SVN supported this ability...not sure about Git). > > > On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < > rajani.karut...@citrix.com> wrote: > > > Hi all, > > > > > > > > Our current git workflow is confusing with the *forward branches and > > cherry-picking. Its hard to track on what all releases the commit has > > gone into unless I do some git log greping. Also, as a contributor, I > > endup creating patches for each branch as it doesn’t cleanly apply on > > different branches. > > > > > > > > I think we should have some guidelines. Here is what I propose. > > > > > > > > 1. There should be branch for every major release(ex: 4.3.x, 4.4.x, > > 5.0.x,5.1.x) and the minor releases should be tagged accordingly on > > the respective branches. > > 2. The branch naming convention is to be followed. Many branches > > with 4.3, 4.3.0, 4.3.1 etc. is confusing > > 3. Cherry-picking should be avoided. In git, when we cherry-pick, > > we have two physically distinct commits for the same change or fix and > > is difficult to track unless you do cherry-pick -x > > 4. There should always be a continous flow from release branches to > > master. This doesn’t mean cherry-picking. They should be merged(either > > ff or no-ff) which retains the commit ids and easily trackable with > > git branch --contains > > * Every bug fix should always flow from minimal release uptill > > master. A bug isnt fixed until the fix reaches master. > > * For ex. A bug 4.2.1 should be committed to > > 4.2.x->4.3.x->4.4.x->master > > * If someone forgets to do the merge, the next time a new commit > is > > done this will also get merged. > > 5. There should always be a continuous flow from master to feature > > branches. Meaning all feature branch owners should proactively take > > any new commits from master by doing a merge from master > > 6. The commits from feature branch will make to master on code > > complete through a merge. > > 7. There should never be a merge from master to release branches > > 8. Every commit in LTS branch(targetted to any minor release) > > should have atleast bug id and correct author information > > * Cassandra's template: patch by <author>; reviewed by <committer> > > for CASSANDRA-<ticket> > > 9. Once the release branch is created(after code freeze), any bug > > in jira can be marked with fix version current release(4.4) only on > > RM's approval and only they can go to the release branch. This can be > > done through jira and with certain rules.(may be using jira vote?) > > this would save the cherry-picking time and another branch maintenance. > > > > > > > > Please add your thoughts/suggestions/comments. > > > > > > > > Ref: > > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html > > https://www.youtube.com/watch?v=AJ-CpGsCpM0 > > > > ~Rajani > > > > > > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
