This is out of my git league, but how do you handle minor versions that way?
Assuming 4.8.0 is the latest stable release and HEAD on master. Then you want to release 4.4.1. First of all can you develop bugfixes for 4.4 along the way, when both develop and master HEAD might be hugely different? Second, can you commit behind HEAD? You don't want the 4.4.1 release instead of 4.8.0 to be HEAD Someone might have good solutions to this, but if not I would propose to keep the release branches for future bugfixes. Erik 25. juli 2014 06:02 skrev "Rajani Karuturi" <rajani.karut...@citrix.com> følgende: > On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mike.tutkow...@solidfire.com> > wrote: > > > I believe I agree with these steps. > > > > A couple questions: > > > > Is 'master' simply always going to be equal to what's the most recent > > version of the code that's in production? > > I think so. master will always be at the latest release and all the > previous releases properly tagged. The release branches would be deleted > once release is done. > > > > > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly > > into RELEASE-4.5? > > > > Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes > should be done on the 4.5 branch. > > > > ~Rajani > > > > > > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi < > > rajani.karut...@citrix.com> wrote: > > > >> > >> Hi Daan, > >> here is what i propose: > >> > >> 1. rename 'master' to 'develop’ > >> 2. branch a new 'master' from '4.4’ > >> 3. branch 'RELEASE-4.5' from the develop > >> 4. merge 'RELEASE-4.5' to master once the release voting is done. > >> > >> RELEASE-4.6 branch should be off develop as all the feature branches > would > >> be merged there before freeze for 4.6 and would be merged to master when > >> the release is voted. > >> > >> The other question I have is in the step:4. how are we going to manage > >> fixes to 4.5 post branch cut? ( assuming no features as the freeze is > done) > >> > >> ~Rajani > >> > >> > >> > >> On 24-Jul-2014, at 11:52 am, Daan Hoogland <daan.hoogl...@gmail.com> > >> wrote: > >> > >>> Mike, Rajani, > >>> > >>> Sebastien's point was that the current 4.4 is the closest we have to a > >>> releasable branch. I don't mind enting on master but it will require > >>> more fixing. In general all of this will require some RM work of all > >>> committers. Please ammend my little proposal if you will. > >>> > >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi > >>> <rajani.karut...@citrix.com> wrote: > >>>> I agree with mike. I think we should start 4.5 from where master is > now > >>>> Also create a develop branch from master and continue future work for > >> 4.6 there. > >>>> > >>>> I am not clear on how the release branches are going to be maintained. > >>>> Are we saying we would create 4.5-RELEASE branch which is essentially > >> same as our current -FORWARD branch and continue cherry-picking? > >>>> > >>>> I would prefer merges to cherry-picks. > >>>> Also, I think we should allow committers to commit to the RELEASE > >> branch after discussing about it on dev@ and have RM closely monitor > them. > >>>> Any commit intended for 4.5 RELEASE should be checked in after > >> discussion in the 4.5 Release branch and then merged to develop branch. > >>>> > >>>> > >>>> ~Rajani > >>>> > >>>> > >>>> > >>>> On 24-Jul-2014, at 1:14 am, Mike Tutkowski < > >> mike.tutkow...@solidfire.com> wrote: > >>>> > >>>>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4 > left > >> off > >>>>> and then merge features from develop into 4.5. > >>>>> > >>>>> Why don't we instead start 4.5 where master is now with the > assumption > >> that > >>>>> since we are past Feature Freeze for 4.5 that master is stable > enough? > >>>>> > >>>>> > >>>>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland < > >> daan.hoogl...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> so to start formulate a proposal: > >>>>>> > >>>>>> all work shall be done in a new branch (it is advisable to prefix > your > >>>>>> branches with your id) > >>>>>> when working, features will be cherry-picked/merged into the release > >>>>>> branch they are for and next into master. > >>>>>> hotfixes will be done in <branchname>-hotfixes > >>>>>> > >>>>>> as transition we will > >>>>>> > >>>>>> rename 'master' to 'develop' > >>>>>> branch a new 'master' from '4.4' > >>>>>> branch '4.5' from the new 'master' > >>>>>> merge any features from the new 'develop' to '4.5' and 'master' > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen < > run...@gmail.com > >>> > >>>>>> wrote: > >>>>>>> > >>>>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <run...@gmail.com > > > >>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon < > nate.gor...@appcore.com> > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> Let me ask the question, why have master be develop and a release > >>>>>> branch be > >>>>>>>>> "master"? If we are going to follow gitflow, why not just stick > >> with > >>>>>> the > >>>>>>>>> norm? If master is the development branch, it might not be > stable. > >> I > >>>>>> think > >>>>>>>>> the goal here is that we have an obvious stable branch. Anyone > >> could > >>>>>> come > >>>>>>>>> check out master and have the latest useable. > >>>>>>>> > >>>>>>>> I am in favor of following the norm, so ideally master should be > our > >>>>>> stable branch (agreed). > >>>>>>>> > >>>>>>>> The issue is with the transition. > >>>>>>>> > >>>>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so > >> ideally > >>>>>> we could start a stable branch of this tag and build up bug fix > >> releases > >>>>>> all the way to 4.5 from there. > >>>>>>>> > >>>>>>>> But all features for 4.5 are already in master. > >>>>>>>> > >>>>>>>> So if we create a 'develop' branch of master and stabilize > 'master' > >>>>>> then develop is now started from a stable tag (4.4.0). > >>>>>>>> > >>>>>>> > >>>>>>> *not* started from a stable tag, and merges will be tricky, no ? > >>>>>>> > >>>>>>>> So what's the best way to flip ? There is most likely some git > magic > >>>>>> that can we do. > >>>>>>>> > >>>>>>>> > >>>>>>>> The new git workflow and the transition process need to be part > of a > >>>>>> proposal that we get consensus on. > >>>>>>>> > >>>>>>>> getting there :) > >>>>>>>> > >>>>>>>> -seb > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If > >> you > >>>>>>>>> completely squash history, you lose a tremendous amount of > context, > >>>>>> which I > >>>>>>>>> use extensively to figure out why a bug is the way it is. Only > >> knowing > >>>>>> that > >>>>>>>>> the branch was merged at a given point in time doesn't give any > >>>>>> context. > >>>>>>>>> Seeing the individual commit history of the branch helps to > >> preserve > >>>>>> the > >>>>>>>>> rationale for why the code was written the way it was. In theory > if > >>>>>> every > >>>>>>>>> change starts out as a branch (feature, hotfix, release), then > why > >> not > >>>>>> just > >>>>>>>>> merge the branch once it is in a good and acceptable state? > >>>>>>>>> > >>>>>>>>> I also agree with Mike that this will have to be a transition > over > >>>>>> time. It > >>>>>>>>> will take some time to clean up master to the point where it can > be > >>>>>>>>> considered a solid stable branch. Possibly as part of the 4.5 > >> release. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen < > >> run...@gmail.com > >>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland < > >> daan.hoogl...@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Sebastien, > >>>>>>>>>>> > >>>>>>>>>>> It seems we can do what you are calling for is creating a > branch > >>>>>>>>>>> called 'release'. We can merge back into that branch from 4.4, > >>>>>> master, > >>>>>>>>>>> 4.3. I would like to see people that want a feature or bug fix > >> in a > >>>>>>>>>>> branch make a fork of that branch and when that fork is working > >> do a > >>>>>>>>>>> cherry-pick. The -forward concept is now used for that but it > is > >>>>>>>>>>> broken because more then for one piece of work there are > commits > >> on > >>>>>>>>>>> it. This caused me conflicts during the release. Especially > >> painfull > >>>>>>>>>>> as not all was intended to get into the release. We can create > >> this > >>>>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in > >>>>>> changes. > >>>>>>>>>> > >>>>>>>>>> Yes, that's what I am thinking about too, so +1 > >>>>>>>>>> > >>>>>>>>>> Our master would become the -develop- in gitflow terms > >>>>>>>>>> The release branch you mention would become the -master- in > >> gitflow > >>>>>> terms > >>>>>>>>>> > >>>>>>>>>> If we start now, indeed we can create 'release' from 4.4 release > >> tag > >>>>>>>>>> (voted and shipped). > >>>>>>>>>> > >>>>>>>>>> That means that to create 4.5 we will need to merge features > back > >> into > >>>>>>>>>> 'release'. it might be messy because some of those features are > >>>>>> already in > >>>>>>>>>> our current master. > >>>>>>>>>> > >>>>>>>>>> But all of this will keep 'release' clean (we can keep track of > >> bugs > >>>>>> and > >>>>>>>>>> features that are in it in CHANGES file etc..) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> There is a question of control. Do we allow all committers to > >> manage > >>>>>>>>>>> the release? I am for that but can imagine not everybody is. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> At first I would say that only the RM can commit to 'release'. > As > >> we > >>>>>> get > >>>>>>>>>> the CI in place we could relax this and allow commits that pass > >> the > >>>>>> CI to > >>>>>>>>>> get into 'release', but right now I would vote for a tighter > >> control > >>>>>> of > >>>>>>>>>> 'release'. > >>>>>>>>>> > >>>>>>>>>>> rule number 1 will be: you are going to do something to the > >> code, you > >>>>>>>>>>> start by creating a branch. > >>>>>>>>>>> > >>>>>>>>>>> right? > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen < > >>>>>> run...@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit < > >> sam.sch...@appcore.com> > >>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hey everyone, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I've been a developer for a handful of years and have had my > >> share > >>>>>> of > >>>>>>>>>>>>> experience with different version control systems. I've used > >> (for > >>>>>>>>>> better > >>>>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Each of these solutions offers their own unique set of > >> features, > >>>>>>>>>> strengths > >>>>>>>>>>>>> and weaknesses. As there are so many systems that are good > at > >>>>>> specific > >>>>>>>>>>>>> things, it seems best to use the features that the chosen > >> system is > >>>>>>>>>> best at. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Git is great at branching, merging and using that structure > to > >>>>>>>>>> maintain and > >>>>>>>>>>>>> control how changes get into the primary branches. Git tools > >> even > >>>>>> make > >>>>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make > >>>>>> branching > >>>>>>>>>> and > >>>>>>>>>>>>> merging that much easier. It would seem counter-intuitive to > >> NOT > >>>>>> make > >>>>>>>>>> use > >>>>>>>>>>>>> of these built-in capabilities. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In addition to that, I know that the current method of change > >>>>>>>>>> management is > >>>>>>>>>>>>> incredibly frustrating to work with, and works directly > >> against the > >>>>>>>>>> way a > >>>>>>>>>>>>> typical Git user would expect it to be structured. I should > >> NEVER > >>>>>> have > >>>>>>>>>>>>> problem compiling and running something on master. I should > >> not > >>>>>> have > >>>>>>>>>>>>> problems building anything on a release branch. A > >> feature/bugfix > >>>>>>>>>> branch is > >>>>>>>>>>>>> where things can be, and often are, broken or unstable. > There > >> have > >>>>>>>>>> been > >>>>>>>>>>>>> many times working in Cloudstack where I've had to search > for a > >>>>>> stable > >>>>>>>>>>>>> revision on master, and that's just plain wrong. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I do realize that having this many developers working on so > >> many > >>>>>>>>>> features > >>>>>>>>>>>>> and bugfixes will result in a large number of branches. I > >> don't > >>>>>>>>>> believe > >>>>>>>>>>>>> this is a good argument against using a branching method, > >> though - > >>>>>> I > >>>>>>>>>>>>> believe that the current system is even more confusing and > >>>>>> difficult > >>>>>>>>>> to use. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I could pontificate on change management quite a bit more, > but > >> my > >>>>>>>>>> opinion > >>>>>>>>>>>>> in summary would basically be: use Git the way it was meant > >> to be > >>>>>>>>>> used, > >>>>>>>>>>>>> and things will be better. Just my two cents. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Sam > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Sam, I think we are in agreement (at least with folks who > >> responded > >>>>>> to > >>>>>>>>>> this thread). > >>>>>>>>>>>> Or maybe I am not reading your mail right and you don't agree > >> with > >>>>>> Leo ? > >>>>>>>>>>>> > >>>>>>>>>>>> My own take and reason for calling for a change we are > currently > >>>>>> doing > >>>>>>>>>> things is mostly due to the way we release. > >>>>>>>>>>>> > >>>>>>>>>>>> I would like to see a stable master (and I think we are in > >> agreement > >>>>>>>>>> with that). > >>>>>>>>>>>> That means that development should not happen on master and > that > >>>>>> every > >>>>>>>>>> commit that lands on master should be shippable. > >>>>>>>>>>>> > >>>>>>>>>>>> I personally have no issues with cherry-picking. So I would be > >> fine > >>>>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug. > >>>>>>>>>>>> The end result is that the next commit on master would still > >> mean > >>>>>>>>>> master is shippable/releasable. > >>>>>>>>>>>> > >>>>>>>>>>>> If we agree with this basic concept. The question becomes how > >> do we > >>>>>> get > >>>>>>>>>> there, considering that master is now full of dev work and > >> potential > >>>>>> bug. > >>>>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and > >> previous > >>>>>>>>>> release branches. > >>>>>>>>>>>> > >>>>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our > >> way > >>>>>> back, > >>>>>>>>>> merging the new features that are already in master into the new > >>>>>> master > >>>>>>>>>> (based on 4.4). > >>>>>>>>>>>> This could be quite complicated but we need to do it (or > >> something > >>>>>> like > >>>>>>>>>> it). > >>>>>>>>>>>> > >>>>>>>>>>>> To move forward, we should make a proposal to the list and > call > >> for > >>>>>> a > >>>>>>>>>> vote. > >>>>>>>>>>>> > >>>>>>>>>>>> Any takers to start a wiki page proposing a new git process > and > >> how > >>>>>> we > >>>>>>>>>> could move to it (transition path) ? > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -Sebastien > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons < > >>>>>>>>>> lsim...@schubergphilis.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hey folks, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and > >> implement > >>>>>> this? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a > >>>>>>>>>> committer so > >>>>>>>>>>>>>> its not that practical for me to volunteer! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> which might be easier to read. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Similarly, the git-flow scripts that help out with > >> implementing > >>>>>> this > >>>>>>>>>> stuff > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://github.com/nvie/gitflow > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> they also describe the relationship between gitflow and > >> dealing > >>>>>> with > >>>>>>>>>>>>>> multiple remotes > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in > >> support > >>>>>> for > >>>>>>>>>>>>>> git-flow > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://www.sourcetreeapp.com/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Because cloudstack currently is full of rebasing and > >> squashing and > >>>>>>>>>>>>>> cherry-picking, you get very little benefit from a tree > >>>>>> visualization > >>>>>>>>>> tool > >>>>>>>>>>>>>> (like this or gitk or ...) right now, but it would be > *great* > >> to > >>>>>> have > >>>>>>>>>> going > >>>>>>>>>>>>>> forward. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> cheers, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Leo > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen < > >> run...@gmail.com > >>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I would like to re-start this discussion. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thinking about our release procedure, we clearly need more > >> tests > >>>>>> and > >>>>>>>>>> a > >>>>>>>>>>>>>> CI. However it looks like this is going to take some time. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In the meantime I think there is nothing preventing us from > >>>>>> agreeing > >>>>>>>>>> to > >>>>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just > >> need to > >>>>>>>>>> agree on > >>>>>>>>>>>>>> the git workflow. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Right now Master is really a development branch, we should > >> make > >>>>>> it a > >>>>>>>>>>>>>> stable branch for production with very few commits. > >>>>>>>>>>>>>>> This does not mean that we would release less, in contrary > >> this > >>>>>> would > >>>>>>>>>>>>>> ensure that a commit to master means it's a production > >> release. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back > >> to > >>>>>>>>>> Rajani's > >>>>>>>>>>>>>> point) everything is based on merges. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am of the opinion that git flow provides a nice process. > It > >>>>>>>>>> basically > >>>>>>>>>>>>>> freezes master. Development happens in a 'develop' branch, > >>>>>> releases > >>>>>>>>>>>>>> branches are branched off of that and merged into master and > >> back > >>>>>> into > >>>>>>>>>>>>>> develop….etc > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Please read [1] it's a good read. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> And let's discuss, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> [1] > http://nvie.com/posts/a-successful-git-branching-model/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Sebastien > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi < > >>>>>>>>>> rajani.karut...@citrix.com> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> There is also the problem of cherry-picking. > >>>>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches > >> for > >>>>>> each > >>>>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches. > >> which > >>>>>> means > >>>>>>>>>>>>>> distinct commits for each branch and I don’t easily know > >> which all > >>>>>>>>>> branches > >>>>>>>>>>>>>> my commit exists unless I do grep. > >>>>>>>>>>>>>>>> if we follow merging strategy properly, apart from the > first > >>>>>> merge > >>>>>>>>>> of > >>>>>>>>>>>>>> the branch, everything else on top of it should be a > painless > >>>>>> merge. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ~Rajani > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <shadow...@gmail.com> > >>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I think many of the bullet points are what we are > currently > >>>>>> doing > >>>>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to > >> stay > >>>>>> in > >>>>>>>>>> sync > >>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>> master, no back-merging). I also think that much of what > >> we do > >>>>>> now > >>>>>>>>>> is > >>>>>>>>>>>>>> done > >>>>>>>>>>>>>>>>> the way it is simply because there *are* vast changes > >> between > >>>>>>>>>> versions. > >>>>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the > >> time. > >>>>>> If > >>>>>>>>>> its > >>>>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine, > but > >> some > >>>>>>>>>> quick > >>>>>>>>>>>>>> tests > >>>>>>>>>>>>>>>>> seem to indicate that this will be messy getting started. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with > >> having > >>>>>> single > >>>>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits > >> where > >>>>>> each > >>>>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to > remember > >>>>>> why we > >>>>>>>>>> went > >>>>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list > >>>>>> somewhere, but > >>>>>>>>>>>>>> one of > >>>>>>>>>>>>>>>>> the nice things it provides is the ability for the > release > >>>>>> manager > >>>>>>>>>> to > >>>>>>>>>>>>>>>>> control what changes are made during code freeze while > >> giving > >>>>>>>>>> people a > >>>>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not > always > >>>>>>>>>> followed). > >>>>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have > >> their > >>>>>> own > >>>>>>>>>>>>>> repo and > >>>>>>>>>>>>>>>>> issue pull requests for bugfixes? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi < > >>>>>>>>>>>>>> rajani.karut...@citrix.com> > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Any other suggestions/objections/comments?? > >>>>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process?? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> ~Rajani > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi < > >>>>>>>>>>>>>> rajani.karut...@citrix.com> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a > empty > >>>>>>>>>>>>>> merge(merge -s > >>>>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not > >>>>>> bring in > >>>>>>>>>> any > >>>>>>>>>>>>>>>>>> changes. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a > major > >>>>>>>>>> rewrite, we > >>>>>>>>>>>>>>>>>> could stop merging to that branch and above and make the > >> fix > >>>>>>>>>> manually. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> ~Rajani > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski < > >>>>>>>>>>>>>>>>>> mike.tutkow...@solidfire.com> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> 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 > >*™* > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Daan > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> *Nate Gordon*Director of Technology | Appcore - the business of > >> cloud > >>>>>>>>> computing® > >>>>>>>>> > >>>>>>>>> Office +1.800.735.7104 | Direct +1.515.612.7787 > >>>>>>>>> nate.gor...@appcore.com | www.appcore.com > >>>>>>>>> > >>>>>>>>> > >> ---------------------------------------------------------------------- > >>>>>>>>> > >>>>>>>>> The information in this message is intended for the named > >> recipients > >>>>>> only. > >>>>>>>>> It may contain information that is privileged, confidential or > >>>>>> otherwise > >>>>>>>>> protected from disclosure. If you are not the intended recipient, > >> you > >>>>>> are > >>>>>>>>> hereby notified that any disclosure, copying, distribution, or > the > >>>>>> taking > >>>>>>>>> of any action in reliance on the contents of this message is > >> strictly > >>>>>>>>> prohibited. If you have received this e-mail in error, do not > >> print it > >>>>>> or > >>>>>>>>> disseminate it or its contents. In such event, please notify the > >>>>>> sender by > >>>>>>>>> return e-mail and delete the e-mail file immediately thereafter. > >> Thank > >>>>>> you. > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Daan > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> *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>*™* > >>>> > >>> > >>> > >>> > >>> -- > >>> Daan > >> > >> > > > > > > -- > > *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>*™* > >
