On Wed, Aug 6, 2014 at 9: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). >
You aren't aiding your case by suggesting that we use experimental tooling. So removing a release branch worries me. Will there be loss of commit information? I know that heretofore, each release has contained commits that aren't in master. Whether that's good, bad or indifferent, that is the fact, and I personally think that is unlikely to change in the short term. Or put more succinctly, what does removing a release branch buy us? So I like most of the things about this proposal - I like doing all the work in the feature/bug branches. But the rest of this workflow befuddles me a bit. I don't think that the workflow will result in a stable 'master' or that we are really doing anything significant by pushing what is master now to become the develop branch. In the page describing this, pushes to the develop branch seem welcome 'when a feature is completed' - so develop will be as messy as master is today, frequently broken, and no improvement in quality. This attempts to solve a quality problem with workflow, and I don't think it can do that. Instead, we end up with develop being cluttered and as messy as current master, and we spend time trying to get merge commits from develop -> master and hoping things don't diverge so far in our release branches that we can merge fixes from develop -> master -> release-branches. This is a bit of a change from what we are doing now; why are we doing it? A stable master? I am not sure how a workflow change enforces a stable master. Improved quality? A workflow change might be a part of the solution, but there seems to be missing something that enforces quality or gates on working functionality. --David
