"Once you merge release branch it on master/stable branch, you don’t lose commit if you delete it. It’s like removing a feature branch once it’s merged on master/target branch."
Correct. At t his point your "release" is in master. If you need to bug fix, you checkout that tag from master. Also, as far as CI is concerned it should be ran on the feature branch and once the feature doesn't break anything, it should only then be merged into develop. http://twasink.net/2011/09/20/git-feature-branches-and-jenkins-or-how-i-learned-to-stop-worrying-about-broken-builds/ http://juristr.com/blog/2014/01/git-flow-jenkins-gitlab/ The idea is that you are not pushing a broken feature into a branch. On Wed, Aug 6, 2014 at 10:55 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi David, > > On 06-Aug-2014, at 4:10 pm, David Nalley <da...@gnsa.us> wrote: > > > 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. > > No, if you know you git-chops you can do it by hand, I mean to say -- the > tool is under development for support stuff. > > > So removing a release branch worries me. Will there be loss of commit > > information? > > Once you merge release branch it on master/stable branch, you don’t lose > commit if you delete it. It’s like removing a feature branch once it’s > merged on master/target branch. > > > 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. > > Once merged on master/stable branch, one can checkout the release version > tag to get the same branch. > > > Or put more succinctly, what does removing a release branch buy us? > > Less cluttered branches. You’ve the release branch merged on master and > tags why do you want to keep branches? You can always checkout the tags to > get the release branch. > > > 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. > > You’re right. It’s just a convention of doing things, like we’ve traffic > rules. > They won’t stop you to break anything if you don’t follow. > > > 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. > > I’m not here to "defend git-flow", I like it just because IMO it's better > than status quo. > > We have several threads on this issue now, it adds divergence to the topic > in the community just like length/divergence/state/stability between > release branches and master which need to be fixed, so we need some sort of > protocol/convention that we all agree to. That’s all :) > > Let me list out the things I want with our workflow(s) (adaptation from > git-flow and other places etc.; skipping posting video) > > - Baseline protocol, continuous flow of changes and respect for the “tofu > scale": More -- http://markmail.org/message/4hk2jwvxt4lcpqig > - Shorter release cycles, less divergent branches (release and master) > - Make it less painful for RMs and other participants during release, by > deciding on a sync rule — sync from release branches to master; bug fixes > go on release branch first, not master > - Automation in testing (we've CI and WIP efforts) > - Contributors test their code, don’t break stuff, participate in release > process. The 4.4.0 IMHO was the worst, low community participation, > QA/testing > - You work on ACS first, use it as upstream — you work on ACS and let > changes trickle down to your distribution, not the reverse direction > - Influence committers improve their git skills and have ethics when > working together in the community, follow conventions, push short > revert-able commits, add design docs and on wiki > - Convention of branches: prefix namespaces -- “bugfix/“ for bugfixes, > “support/“ for LTS releases, “release/“ etc. > - Rolling releases (or shorter release cycles) on support branches for LTS > > > > 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. > > If there is any way I can help, I would prefer a discussion either on IRC > or on Hangout/Skype/GTM instead of contributing to the length of these > thread anymore. > > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > M. +41 779015219 | rohit.ya...@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > Find out more about ShapeBlue and our range of CloudStack related services > > IaaS Cloud Design & Build< > http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > CloudStack Infrastructure Support< > http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training Courses< > http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based > upon its contents, nor copy or show it to anyone. Please contact the sender > if you believe you have received this email in error. Shape Blue Ltd is a > company incorporated in England & Wales. ShapeBlue Services India LLP is a > company incorporated in India and is operated under license from Shape Blue > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil > and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is > a company registered by The Republic of South Africa and is traded under > license from Shape Blue Ltd. ShapeBlue is a registered trademark. >
