I think the core difference between your implementations is that #1 assumes that BVT/CI will catch 100% of errors, resulting in a stable master branch with no problems. Or that development changes can be blindly merged if they pass CI. The goal of git-flow is to allow a stream of development changes that don't impact the stable release or process, and the process of making a release is assumed to take a separate effort and cleanup.
The other major benefit that I think is getting missed by having a stable master branch is an ease with creating hotfixes. Sure, you can branch from a tag in a development branch, but it feels cleaner to me to branch from the release branch and then selectively merge back into any other affected areas. On Tue, Aug 5, 2014 at 3: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 > * 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 > >>> > >>> > >> > > > > -- *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.
