Sustaining releases #288

onlynone opened this Issue Dec 14, 2012 · 0 comments

1 participant



I was considering using gitflow and I was wondering how these tools and this branching methodology in general handle older sustaining releases that just receive bug fixes?

Let's say my current release is 1.5.0 and there's an issue which requires a hotfix. I make the hotfix branch off master, make the fix, up the version to 1.5.1 and merge it back into master and develop. That's cool for my 1.5.x release and the develop branch. But what about my 1.4 branch that has the same bug and that I still support? I'd like to make a 1.4.1 release that only differs from 1.4.0 by having the hotfix cherry-picked onto it.

Would I just manually do the cherry-pick to my 1.4.0 tag and then tag the result as 1.4.1? That version wouldn't be reachable from any branch... it seems weird. Our existing branching methodology is to make a 1.4.x release branch which we tag as 1.4.0 when it's ready to release. We cherry-pick bug fixes to this branch and when we're ready for a new release, we tag it with 1.4.1 and so on. We do this with any release branch that we continue to support. Anyone who wants a specific version can grab a specific tag, or just grab HEAD of any release branch to get the most up-to-date version of that branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment