Erik, addressing "What's the downside of having master represent the latest released version?²
No real downside (rather than the pain when it comes to managing maintenance releases for earlier versions of CS), but what are the advantages really? If you are the user who wants to get the latest stable release, you just get it from the release branch (or specific tag on that branch if you want a particular minor release), the release branch that - again - we must keep around because of subsequent maintenance releases that we support in CS. Unlike in git-workflow, when release branch is removed right after its merged to master. And if you are a RM who wants to cut the release, you do it from the stable branch with the latest code. And that branch won¹t be master. So why implement something that doesn¹t serve any practical purpose for CS? I don¹t argue against other items of git-workflow (merges vs cherry-picks, feature/hotfix branches), my main concern is about master branch maintenance. =Alena. On 8/7/14, 2:17 PM, "Erik Weber" <terbol...@gmail.com> wrote: >On Thu, Aug 7, 2014 at 10:44 PM, Alena Prokharchyk < >alena.prokharc...@citrix.com> wrote: > >> Daan, thank you. Please see my comments inline. >> >> >> On 8/7/14, 1:19 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >> >> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk >> ><alena.prokharc...@citrix.com> wrote: >> >> Plus if you read the discussion below the article, you will see that >> >> people agree that this model doesn¹t work well for the case when the >> >> product support maintenance for older releases, like CS does. >> > >> >Not at all, Alena. I don't agree that this model won't work for CS and >> >I think you are over estimating the amount of people that think so. >> >This model does work using support branches. It will work very well in >> >the CS case and is not very far removed from what we are doing right >> >now. There will always be port work when fixes in older versions need >> >to be made. You don't merge back support branches to tag the >> >maintainance release on the master branch. The fix-release-tag can >> >remain on the branche whether it is merged back or not. The witch hunt >> >on cherry picking is only perceived. There will be occasions it is >> >necessary but seldom so. >> >> >> Does it mean that our master branch will miss the fixes from support >> branches? Or you say we should cherry-pick them all on the top of the >> master branch. >> > > >'master' reflects the latest released version. If that release misses the >fix, then master does as well. >For master to have it you would either roll out a new version or hotfix >it. > > > >> Again, I don¹t see how maintaining master branch to reflect the latest >> release branch, can stabilize our release process. You will still >>continue >> to cut the release branches from *develop, which you can¹t really call >> ³stable² with this model. >> >> >It doesn't. master could just as easily have been called 'stable' or >'latest'. > > >> >> I¹m still convinced that the best solution in our case would be >> introducing: >> >> * develop branch as a staging branch >> > >develop is the staging branch in gitflow as well, you do your development >in feature branches. >when your feature is done and passes CI you merge to develop. > > * merging develop branch to master on a regular basis after the CI test >> passes >> > > >there's no guarantee that it's stable at all, CI can only cover so much. >besides, this is what gitflow proposes, except that you merge from your >feature branch to develop, instead of from develop to master. > > > >> * cut release branch from the stable master branch when its time for >>the >> release >> > >see previous, besides if the only thing deeming if master is stable or not >is CI, then you might as well cut from develop > > > >> I¹m really trying to find the advantages of git-flow model where master >> reflects the latest release branch, and can¹t find any considering that >>in >> the CS we are still going to keep those release/support branches, and if >> people need the latest release code, they can simply get it from there. >> >> >What's the downside of having master represent the latest released >version? > > >> From the developer stand point, I would be more interested in getting >>the >> latest stable code, not the latest stable release. And with the model I >> propose, that would be the master branch you get the latest stable code >> from. >> > >So you have to do a 'git checkout develop' first. unless you use the >gitflow tools, >then you do a simple 'gitflow feature start <feature-name, bugid or >similar>' and don't really care >about branch names at all. > > >> From release management perspective, I would be more interested in >>cutting >> the release branches from the stable branch - gitflow suggests to cut it >> them from *develop branch rather than master - and *develop is not a >> stable branch. I don¹t see the use of stable master branch during the >> release, as it reflects already released versions of the CS. >> > >develop should be as stable as the master you propose, after all they >should contain the same code. > > > >> May be I am missing the point. Would appreciate people explaining the >> purpose of a git-flow way of keeping master branch, to solve the >>existing >> CS problems. Just because ³its a best practice for others² doesn¹t sound >> very convincing. >> > > >If the master branch is what confuses you the most, then forget about >master branch. >As a developer you are not really interested in it anyway, you never >really >commit to it besides new releases / hotfixes to the latest release. >Think of develop as your master and treat it like that, and think of >master >as a shortcut to the latest release tag. > >-- >Erik
