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
