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.
