Supporting multiple versions with Successful Git Branching Model

Question

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!

Answer 1

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