up vote 1 down vote favorite
1

At our company we are moving from SvN to Git (yeah, better late than never). With that, we also try to streamline the versioning process. To do that I found an interesting article: Successful Git Branching Model by Vincent Driessen.

As far as I can read from the article, developer assumes linear releases. To be clear:

v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc

Support for older releases is not mentioned. For example: we support up to three major versions back because some clients do not want to upgrade. So imagine we have the following versions:

v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0

When there is a critical bug found in v8.0.0 after the release of v9.0.0, we checkout tag v8.0.0, fix bug, and merge it back into develop and master branches. Merge into master gets tag v8.0.1.

Seems to me somehow weird because of two things:

  1. The master timeline will look like v7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0. I'm totally aware it's possible, but is it also acceptable?
  2. When I merge from hotfix to master (and master is at that moment at v9.0.0) and tag it with v8.0.1, do I also get features introduced between v8.0.0 and v9.0.0?

Thanks in advance!

share|improve this question
54% accept rate
feedback

1 Answer

up vote 2 down vote accepted

To me, the tag v8.0.1 should be the commit before the merge master. If you want to patch the new versions, then you merge the other tags there as well.

v8.0.0 --> v9.0.0 --> v10.0.0
   \          \           \
  v8.0.1 --> v9.0.1 --> v10.0.1/master
share|improve this answer
Thanks! I probably misunderstood the concepts of tagging in Git in first place :) Did'nt realized I can tag the hotfix itself, as opposed to merging into develop/master and then tagging. Thanks! – Ivan 2 hours ago
feedback

Your Answer

 
or
required, but never shown
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.