Rohit, whatever you say below, just proves our original worry about handling the maintenance minor releases (see my comments below). We can’t possibly adopt the way where release branches get removed since we always support maintenance releases for multiple versions at a time: 4.2.1, 4.3.1, 4.4.1.
Thanks, Alena. On 8/6/14, 11:06 AM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >Hi, > >On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: > >> Rohit, thank you for the explanation. So we cut the maintenance release >> from the master branch, not *develop as opposed to the major release >> branch. >> >> One more open question. Its clear that we cut the maintenance release >>from >> the master branch, but what would be the right way to merge it back if >> this is a maintenance release for say 4.2, and 4.4 is the top of the >> master branch? Where would the 4.2.1 tag appear? It can’t be on a top of >> 4.4 > >You checkout a support branch from 4.2 tag (or for that matter you may >keep the 4.2 release branch, it’s same) for LTS/support. >You tag 4.2.1 on the support branch. (it’s the same way you would do like >we do it now). I think git-flow is suitable for rolling releases and may >not 100% work with our deployment/release process. One thing I’ve >suggested is shortening of our release cycles which can help. The argument - "I’ve suggested is shortening of our release cycles which can help.” - can’t be taken to consideration as its not implemented. Only after its implemented, and we agree that we don’t support minor releases, then we can use it. > >The flow of commits/fixes/changes would follow the baseline protocol — >from firm branch to soft branches chronologically, so if there is a bug >on 4.2 release you fix it on 4.2 support branch and >cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and >then to 4.4 support branch … to 4.5 release branch to develop branch. So we do keep the releases branches? :) Which what “support” branch eventually becomes. You get rid of release branch by merging and tagging it to master, but eventually you bring it back once its time for minor maintenance release, but now call it “support”. And if you are cutting support branch for 4.2.1, you need to merge changes to all the branches on master! By creating support branches for 4.2, 4.3, 4.4, 4.5. That doesn’t seem like a valid model to me. > >I think git-flow assumes the releases will be chronological so you don’t >release 4.3.1 after 4.4 etc and you always progress? I’m not sure. >We can think of better ways of doing things, we can also learn from how >other projects do it. That’s what I was afraid of, and already pointed it out that the model the article suggest, suits only SAAS like models, when there is no support for minor maintenance releases. > >Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be >painful, that always felt to me like maintaining a whole different >product. If we can do something about that, we’re going to make a lot of >people happy IMO. > >> >> >> All the above should be documented in the proposal. The original >>proposal >> didn’t mention anything about how we are going to do maintenance >>branches. >> And we were originally thinking about leaving the release branches >>around. >> >> Thanks, >> Alena. >> >> >> On 8/6/14, 10:16 AM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >> >>> >>> On 06-Aug-2014, at 6:58 pm, Alena Prokharchyk >>> <alena.prokharc...@citrix.com> wrote: >>> >>>> Why implement something that doesn¹t serve any practical purpose for >>>> CS?? >>>> We should adopt only things that would address current CS problems - >>>> regressions, unstable releases, etc. That would mean - running the >>>> automation (CI, BVT) on *develop branch, cut the *fix branches for hot >>>> fixes/critical/feature bugs only and run BVT on them before merging to >>>> *develop; merge only stable code from *develop to master branch. >>>> >>>> There would be no use for master branch if it reflects the latest >>>> release >>>> branch, which will always be present in CS model as opposed to what >>>> original article suggests. Below the explanation from the other email >>>> thread on why the release branches can¹t be removed in CS model: >>>> >>>> Rohit: >>>> ================ >>>> >>>> "IMO We ³should" remove the release branches when done. Instead there >>>> is a >>>> support workflow with git-flow (see support >>>> http://yakiloo.com/getting-started-git-flow/) and also in the tooling >>>> (git >>>> flow support etc. though experimental).² >>>> >>>> Alena: >>>> ========== >>>> If we remove the release branches, how are we going to handle >>>> maintenance >>>> releases for older versions of the code? It wouldn¹t work as its >>>> impossible to cut a maintenance release from develop branch. >>> >>> When you merge --no-ff a release/any branch on master/target branch, >>>the >>> version history stays with it. >>> Not only we merge it on master, we do a tag on it as well. Now to get >>>the >>> history/branch back you can always checkout the tag: git checkout <tag> >>> and see the history: >>> git log --graph --decorate --pretty=oneline --abbrev-commit —all >>> >>> So, it’s safe to delete a branch when it’s merged to a target/master >>> branch. >>> If you have never deleted a feature branch once it was merged, you >>>should >>> try and see for yourself. At the end of the day, git is all but >>>link-list >>> logic at the core. The branch too tracks just the HEAD, if you’ve >>> refs/tag/sha of a branch you can checkout to get the branch back. >>> >>> When a branch is merged, git allows you do delete the branch with: git >>> branch -d <release>, if branch is not merged you’ve to force it with >>>-D: >>> git branch -D <release> >>> To cut a maintenance release from a release version, all you’ll have to >>> do it: >>> git checkout -b <support-branch> <tag> >>> >>> HTH. >>> >>>> I think the model the article proposes, fits the products like SAS, >>>>when >>>> there are no maintenance releases and support is provided just for the >>>> latest release. Then of course, to get the latest stable release, it >>>> would make sense to access master branch which is always stable. In >>>>case >>>> when multiple releases are being maintained at the same time - like >>>>CS - >>>> it would make sense to keep release branches. Otherwise how are you >>>> going >>>> to handle this situation: >>>> >>>> 4.2, 4.3 and 4.4 are released >>>> Master reflects 4.4 >>>> Maintenance 4.2.1 and 4.3.1 releases are needed >>>> >>>> Questions: >>>> How do you create those releases, from what branch? >>>> How do you merge and tag them into master branch considering that the >>>> latest version there is 4.4? >>>> >>>> Thanks, >>>> Alena. >>>> >>>> >>>> >>>> >>>> On 8/5/14, 11:36 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >>>> >>>>> Exactly Rajani, and other solutions are possible. The issue is not >>>>>how >>>>> branches are called ;) >>>>> >>>>> On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi >>>>> <rajani.karut...@citrix.com> wrote: >>>>>> I am just wondering if the shift to a new develop branch is causing >>>>>> the >>>>>> problems. Its a simple branch shift and should be no different from >>>>>> the >>>>>> current master. >>>>>> >>>>>> may be we should leave the master as is and create a Œstable' branch >>>>>> which would act like master in git-flow ? >>>>>> >>>>>> ie) >>>>>> ACS master -> develop in git-flow >>>>>> ACS stable -> master in git-flow >>>>>> >>>>>> >>>>>> ~Rajani >>>>>> >>>>>> >>>>>> >>>>>> On 06-Aug-2014, at 10:56 am, Daan Hoogland <daan.hoogl...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hello devs and especially committters, >>>>>>> >>>>>>> I see some -1s coming by, days after the vote was closed. That is >>>>>>> disturbing as it means we accepted a proposal that will not be >>>>>>> supported by the community. So let me try to find that support in >>>>>>> hindsight; >>>>>>> >>>>>>> The argument of Animesh that we are shifting the burden from one >>>>>>> branch to another is real and present danger. I share his concern. >>>>>>>It >>>>>>> is not the only feature of this proposal and in it self does not >>>>>>> warrant a -1. It does not worsen the situation at hand or add to >>>>>>>our >>>>>>> workload in any way. If there is no advantage to you and no >>>>>>> disadvantage either then why -1 something that others do find >>>>>>>useful? >>>>>>> This is 'kind of' a rhetorical question. It is a real concern, >>>>>>> however >>>>>>> though not the biggest at this moment. >>>>>>> >>>>>>> branching is recommended but as people are rightfully wondering >>>>>>> "should I make a branch for a single line fix". I would, probably >>>>>>>but >>>>>>> maybe not always. That doesn't mean you must. In case you are >>>>>>>making >>>>>>> a >>>>>>> fix on a release then yes you do. It is how the git-flow workflow >>>>>>> goes. >>>>>>> >>>>>>> Committers can merge and commit where ever they feel the need. That >>>>>>> doesn't exempt them from thinking if it is a good idea. It doesn't >>>>>>> now >>>>>>> and it won't in the future. Doing what your boss tells you to do >>>>>>>can >>>>>>> be a crime! >>>>>>> >>>>>>> Reverting something should only be done when the code that is a >>>>>>> culprit has been identified. Reverting a big change or even a bunch >>>>>>> of >>>>>>> changes is a cowards way out. We shouldn't do it now or using >>>>>>> gitflow. >>>>>>> It is not really related to git flow or its use. So we shouldn't >>>>>>> penalize developers that didn't cause a problem or ones that did. >>>>>>>We >>>>>>> should help them help us make a better system. >>>>>>> >>>>>>> The question of why this process isn't implemented on master is >>>>>>> valid. >>>>>>> It could. It isn't however. It is a choice the authors of gitflow >>>>>>> made. I think it is not really the time anymore to be nitpicking >>>>>>> about >>>>>>> this. Unless we find a very valid reason to alter the accepted >>>>>>> proposal we should all try and implement it as good as possible. I >>>>>>> have been RM for 4.4.0 and one thing I don't want anymore is people >>>>>>> share a 4.4-forward to cherry-pick commits from. It caused me a lot >>>>>>> of >>>>>>> headaches. >>>>>>> >>>>>>> The release is what drives the merges back to master according to >>>>>>> git-flow. We can decide that we define a number of prerelease dates >>>>>>> at >>>>>>> which we merge as well. We don't have to do it at that date but can >>>>>>> decide to do that the next day or week as well. This would kind of >>>>>>> resemble Alena's #1 (as opposed to the more pure gitflow #2). An >>>>>>> argument for #2 is that I don't think every customer greps the rpms >>>>>>> for some release. I know our operators at Schuberg Philis >>>>>>>investigate >>>>>>> the code and check it out from git. They like to compare release >>>>>>>and >>>>>>> look at the latest easily. just checking out master would be very >>>>>>> convenient for them. Of course they can check out a branch as well. >>>>>>> But I doubt if they know exactly what to checkout then. I usually >>>>>>>see >>>>>>> them just look at the latest for a branch. >>>>>>> >>>>>>> All in all, I am very skeptic on whether this will work as planned. >>>>>>> It >>>>>>> is us who need to work neatly and only if we do that we can help >>>>>>> ourselves with improving our process. I do feel that the present >>>>>>>way >>>>>>> of working, mainly the use forward branches but in general the lack >>>>>>> of >>>>>>> using branches to test individual changes, is hindering us in doing >>>>>>> releases. The proposal at hand is very good but can only work if >>>>>>> supported by the people that need to work with it. It doesn't do >>>>>>>our >>>>>>> release process for us. We still need to do it and not just program >>>>>>> some code and check it in. That will never work in any process. >>>>>>>Your >>>>>>> code is not done until somebody somewhere finds it worth running it >>>>>>> in >>>>>>> a production environment. So let's keep discussing and educating >>>>>>>each >>>>>>> other. >>>>>>> >>>>>>> done ranting, feel free to react or contact me in person >>>>>>> Daan >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote: >>>>>>>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <terbol...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle >>>>>>>>> <prachi.da...@citrix.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I fail to understand how will this model help us with the >>>>>>>>>> maintenance >>>>>>>>>> releases? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> That's what gitflow support branches is for. >>>>>>>>> I find this quite descriptive: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/Aw >>>>>>>>>VH >>>>>>>>> 06 >>>>>>>>> CuKT0J >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> For CloudStack we also keep working on prior releases and ship >>>>>>>>>>out >>>>>>>>>> maintenance releases. >>>>>>>>>> I suppose we will be cutting the maintenance releases from the >>>>>>>>>> release >>>>>>>>>> branches? So we will have to keep around the release branches >>>>>>>>>>for >>>>>>>>>> that >>>>>>>>>> purpose. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I've asked earlier, but what is the policy on old releases? How >>>>>>>>> long >>>>>>>>> do we >>>>>>>>> support them? >>>>>>>>> >>>>>>>>> >>>>>>>> Today (e.g. subject to change) we claim to support as a community >>>>>>>> the >>>>>>>> two >>>>>>>> most recent feature releases. (for instance, we just stopped >>>>>>>>support >>>>>>>> the >>>>>>>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x >>>>>>>> and >>>>>>>> 4.4.x) We support those feature releases with bug fix releases >>>>>>>>that >>>>>>>> contain >>>>>>>> no additional functionality. >>>>>>>> >>>>>>>> --David >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Daan >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Daan >>>> >>> >>> Regards, >>> Rohit Yadav >>> Software Architect, ShapeBlue >>> M. +41 779015219 | rohit.ya...@shapeblue.com >>> Blog: bhaisaab.org | Twitter: @_bhaisaab >>> >>> >>> >>> Find out more about ShapeBlue and our range of CloudStack related >>>services >>> >>> IaaS Cloud Design & >>> Build<http://shapeblue.com/iaas-cloud-design-and-build//> >>> CSForge – rapid IaaS deployment >>>framework<http://shapeblue.com/csforge/> >>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> >>> CloudStack Infrastructure >>> Support<http://shapeblue.com/cloudstack-infrastructure-support/> >>> CloudStack Bootcamp Training >>> Courses<http://shapeblue.com/cloudstack-training/> >>> >>> This email and any attachments to it may be confidential and are >>>intended >>> solely for the use of the individual to whom it is addressed. Any views >>> or opinions expressed are solely those of the author and do not >>> necessarily represent those of Shape Blue Ltd or related companies. If >>> you are not the intended recipient of this email, you must neither take >>> any action based upon its contents, nor copy or show it to anyone. >>>Please >>> contact the sender if you believe you have received this email in >>>error. >>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue >>> Services India LLP is a company incorporated in India and is operated >>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda >>>is >>> a company incorporated in Brasil and is operated under license from >>>Shape >>> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic >>>of >>> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue >>> is a registered trademark. >> > >Regards, >Rohit Yadav >Software Architect, ShapeBlue >M. +41 779015219 | rohit.ya...@shapeblue.com >Blog: bhaisaab.org | Twitter: @_bhaisaab > > > >Find out more about ShapeBlue and our range of CloudStack related services > >IaaS Cloud Design & >Build<http://shapeblue.com/iaas-cloud-design-and-build//> >CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> >CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> >CloudStack Infrastructure >Support<http://shapeblue.com/cloudstack-infrastructure-support/> >CloudStack Bootcamp Training >Courses<http://shapeblue.com/cloudstack-training/> > >This email and any attachments to it may be confidential and are intended >solely for the use of the individual to whom it is addressed. Any views >or opinions expressed are solely those of the author and do not >necessarily represent those of Shape Blue Ltd or related companies. If >you are not the intended recipient of this email, you must neither take >any action based upon its contents, nor copy or show it to anyone. Please >contact the sender if you believe you have received this email in error. >Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue >Services India LLP is a company incorporated in India and is operated >under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is >a company incorporated in Brasil and is operated under license from Shape >Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of >South Africa and is traded under license from Shape Blue Ltd. ShapeBlue >is a registered trademark.
