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* > 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.
