Rohit, addressing the following comment: "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).”
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. 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/6/14, 6:41 AM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >Hi, > >Comments in-line; > >On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: > >> Rayees, >> >> I think you have the same misunderstanding as a lot of other folks >> (including myself) had in the beginning - seeing develop branch as a >>trunk >> branch that gets merged into master on a regular basis after the BVT/CI >> tests pass. So the master branch reflects the develop branch minus >>changes >> that didn¹t pass the tests and weren¹t merged into master - lets refer >>to >> it as implementation #1 >> >> That¹s not what git workflow/this thread proposes. In git workflow >>master >> branch reflects the latest stable release instead. So for example, we >> released 4.4, and that what you would see the master to be as we merge >>the >> *release branch to master, not the *develop to master. And develop >>branch >> becomes the trunk branch where all the new fixes go to. I would look at >> the master as at the stable branch, where you can track the history for >> all the major releases as for each of them the master branch has >> corresponding tags - lets call it implementation #2 >> >> I still don¹t see many advantages in implementation #2 - making the >>master >> build stable by simply making it reflect the latest release branch. >> Because you: >> >> * never cut the release from master branch > >We’ve a stable branch that gets rolling/continuous releases which is good. > >> * if you are the customer, and need the latest stable code, you download >> the official RPM >> * if you are a developer, you always want to download the latest code, >>and >> that comes from *develop branch >> * if you want to look at the latest stable release, you look at the >> release branch as per CS git workflow implementation we never remove the >> release branches (they are needed for maintenance releases) > >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). > >I’ll create a video to describe what we can do with this workflow, >instead of going back and forth on the ML. >We don’t need to change our workflow, we can learn from this and adapt to >our workflow. > > >> It would be great if anyone can point the advantages of #2 approach over >> #1, as to me #1 seems to be the approach most people will find more >> intuitive and its used a lot in the field. >> >> -Alena. >> >> >> >> On 8/5/14, 1:22 PM, "Rayees Namathponnan" >><rayees.namathpon...@citrix.com> >> wrote: >> >>> How frequent we can planning to merge from develop to master ? during >>> release ? >>> >>> Regards, >>> Rayees >>> >>> >>> -----Original Message----- >>> From: Prachi Damle [mailto:prachi.da...@citrix.com] >>> Sent: Tuesday, August 05, 2014 11:51 AM >>> To: dev@cloudstack.apache.org >>> Subject: RE: [VOTE] git workflow >>> >>> Sorry if this is already discussed, but few areas that are unclear to >>>me >>> with this process are: >>> >>> - does every fix, however minor it be(say a signle line), needs to be >>> developed in a separate branch? And then we have to merge these >>> individual branches to develop for every fix? >>> - In that case will direct check-ins to 'develop' branch be not >>>allowed? >>> - If not, if CI fails on develop branch, how will one know what caused >>> the failure? Was it some direct checkin Vs some feature/fix merged? >>>Will >>> we revert all the small feature/fixes that were merged to develop >>>branch >>> upto the CI baseline? If yes, wont the developers that did not cause >>>the >>> break get penalized unnecessary? >>> >>> - Lastly, why can't this process be implemented on master? Why are we >>> introducing another branch for the same purposes which the master >>>branch >>> usually serves? >>> >>> >>> I am -1 on this. We should not start implementing this until all >>> processes are clear. >>> >>> Prachi >>> >>> -----Original Message----- >>> From: Jessica Wang [mailto:jessica.w...@citrix.com] >>> Sent: Tuesday, August 05, 2014 11:33 AM >>> To: dev@cloudstack.apache.org >>> Subject: RE: [VOTE] git workflow >>> >>> Exactly. This just shifts pain from one branch to another. >>> I don't see any gains from this, either. >>> I vote "-1". >>> >>> Jessica >>> >>> >>> -----Original Message----- >>> From: Min Chen [mailto:min.c...@citrix.com] >>> Sent: Tuesday, August 05, 2014 11:27 AM >>> To: dev@cloudstack.apache.org >>> Subject: Re: [VOTE] git workflow >>> >>> Agree with Animesh. Didn't see any gains from this, we just shift pain >>> from one branch to another, so vote -1. >>> >>> -min >>> >>> On 8/2/14 9:50 PM, "Animesh Chaturvedi" <animesh.chaturv...@citrix.com> >>> wrote: >>> >>>> +0 >>>> >>>> While this protects master with only commits which are merges from >>>> release branch and keeps it clean but the issues that we have shift to >>>> develop branch. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] >>>>> Sent: Thursday, July 31, 2014 3:28 AM >>>>> To: dev >>>>> Subject: [VOTE] git workflow >>>>> >>>>> Hi All, >>>>> >>>>> We had long discussions on the git flow. >>>>> I tried to capture the summary of it @ >>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj >>>>> This is updated on wiki @ >>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git- >>>>> ProposedGitflowbasedCheck-inProcess and is up for a vote: >>>>> >>>>> Can you share your opinion on the proposal? >>>>> >>>>> [ ] +1 approve >>>>> [ ] +0 no opinion >>>>> [ ] -1 disapprove (and reason why) >>>>> >>>>> >>>>> Thanks, >>>>> ~Rajani >>>>> >>>>> >>>> >>> >> > >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.
