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 * 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) 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 >>> >>> >> >
