Hi, If it was not clear, let me re-state — just because I’m participating in this thread does not mean I fully support git-flow, or I am here to defend it.
The proposal thread warriors Rajani, Daan, Leo and others can comment and advise? I like couple of good ideas in it, and I think it’s better than what we do, especially the baseline protocol. I want to take good stuff from it and adapt them to our workflow. As I see now, this won't change our process/workflow a lot or that it can stop bad commits or practices from happening in our repositories. I’ve emailed git-flow’s author about raised issues, will keep everyone posted. Cheers. On 06-Aug-2014, at 8:29 pm, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > > On 8/6/14, 11:22 AM, "David Nalley" <da...@gnsa.us> wrote: > >> On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav <rohit.ya...@shapeblue.com> >> wrote: >>> Hi, >>> >>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk >>> <alena.prokharc...@citrix.com> wrote: >>> >>>> Rohit, thank you for the explanation. So we cut the maintenance release >>>> from the master branch, not *develop as opposed to the major release >>>> branch. >>>> >>>> One more open question. Its clear that we cut the maintenance release >>>> from >>>> the master branch, but what would be the right way to merge it back if >>>> this is a maintenance release for say 4.2, and 4.4 is the top of the >>>> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top >>>> of >>>> 4.4 >>> >>> You checkout a support branch from 4.2 tag (or for that matter you may >>> keep the 4.2 release branch, it¹s same) for LTS/support. >>> You tag 4.2.1 on the support branch. (it¹s the same way you would do >>> like we do it now). I think git-flow is suitable for rolling releases >>> and may not 100% work with our deployment/release process. One thing >>> I¹ve suggested is shortening of our release cycles which can help. >>> >> >> So I suspect that checking out a tag would work. I don't know that >> once we create a tag, that we would be able to merge that back into >> master. Especially true for maintenance releases. How and where would >> we merge 4.5.1 back into master? Moreover, I don't see us getting out >> of checking out the tag, and creating a branch to work in. That means >> we'd delete a branch, check out a tag, create a branch, create a new >> tag, delete a branch - and repeat. >> >> That said, we don't currently have rolling releases - and now you are >> suggesting it may not 100% work. *sigh* > > Dave, you are right, we can¹t. There is no way to merge back minor > releases back to master branch, and preserve the history. The model works > only for rolling releases. So making master reflect release branch won¹t > make sense in CS case. > >> >>> The flow of commits/fixes/changes would follow the baseline protocol ‹ >>> from firm branch to soft branches chronologically, so if there is a bug >>> on 4.2 release you fix it on 4.2 support branch and >>> cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch and >>> then to 4.4 support branch Š to 4.5 release branch to develop branch. >>> >>> I think git-flow assumes the releases will be chronological so you >>> don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not sure. >>> We can think of better ways of doing things, we can also learn from how >>> other projects do it. >>> >>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be >>> painful, that always felt to me like maintaining a whole different >>> product. If we can do something about that, we¹re going to make a lot of >>> people happy IMO. >>> >>>> >> >> So we've set the expectation that we'll follow SemVer - and adhering >> to that is a good thing. Rolling releases are interesting, but we are >> a long way from being able to do anything remotely close IMO. 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.
