How to version bug fix of library for earlier release?

Question

I'm kinda new in versioning.

In my scenario, for example, our main project is currently developing in 2.1.0 (develop branch), while the library version remain same as 1.5.0 since nothing change (for both 2.1.0 and 2.0.0 release).

So, few questions

1. If later on, we introduce some backward compatible fix in the library in 2.1.0 (develop branch), the version should be changed to 1.5.1, right? But if somehow we need to release 2.0.1 (due to bug on other project), the build will auto includes 1.5.1 in it (since we set to get the latest compatible version), is this practice correct?
2. If somehow later on, we need a hotfix in the library in 2.0.1 release (2.0.x branch), I should increase the version of library to 1.5.2?
3. Then, how about the library reference in 2.1.0, should I update it to 1.5.2?
4. Should I create branches (develop, 2.0.x) for the library following the release version as well?

Answer 1

When developing a system consisting of a main program and libraries, we have to distinguish between the version numbers of the parts as well as the version number of the system as a whole:

 [Main: V2.1.0] ->  [Library: V1.5.0]
 [------ System: Version 3000   ----]

However, it is not uncommon to give the whole system the same version number as the "main program", especially when all parts are always deployed together, and I assume that is your situation here:

 [Main: V2.1.0] ->  [Library: V1.5.0]
 [-------- System: Version 2.1.0 ---]

The point in time when the "System" gets its version number officially is usually the "release time". That may be a release to a test environment, staging environment or production, depending on your development process. Bus as soon as the version number is published, any change of the parts will not trigger a new version number of the parts, but also a new version number of the system. And as soon a part has been released with a certain version number, there should no other release with the same version number, but different content.

Now to your question: let us assume you have released V2.0.0 in the past

  [Main: V2.0.0] ->  [Library: V1.5.0]
  [-------- System: Version 2.0.0 ---]

and now you have to rerelease it with a hot fix. Normally, for a hot fix, you want to only to fix a bug, don't want to introduce new features and minimize the risk of getting new bugs due from newer feature development. So if that can be done by only fixing a bug in "main", you will get

  [Main: V2.0.1] ->  [Library: V1.5.0]
  [-------- System: Version 2.0.1 ---]

But maybe you also want to include the bug fix introduced in V1.5.1 in the hot fix V2.0.1. (I would also increase the system's version number, and hence the main program's version number, even if the newer lib is the only change). This depends a lot on the nature of this fix, what else was changed from V1.5.0 to V1.5.1, and if this will also need additional changes in "main" which otherwise were unnecessary. So there is a risk analysis required.

the build will auto includes 1.5.1 in it (since we set to get the latest compatible version)

Well, that is usually a bad idea - as I pointed out, if you keep 1.5.0 in your hot fix, or switch to 1.5.1 is a decision you want to make deliberately. Using always the "newest version" is not a decision the environment can make for you automatically in a sensible manner. Library upgrades should be planned, especially in hot fixes.

If somehow later on, we need a hotfix in the library in 2.0.1 release (2.0.x branch), I should increase the version of library to 1.5.2?

What your version 2.0.2 requires is again subject of a risk analysis. Assumed libs 1.5.0 and 1.5.1 both contain still a bug which must be fixed in System 2.0.2, a new version 1.5.2 may be necessary for this. However, depending on what has happened in between, the risk analysis may tell that it is less riskier to patch lib 1.5.0 and release it as 1.5.0.1.

Then, how about the library reference in 2.1.0, should I update it to 1.5.2?

What would be the alternative? Staying with 1.5.1 and leave the bug in? In case 1.5.2 contains mainly bug fixes (in comparison to 1.5.1), it is a usually good idea not to introduce already fixed bugs again in newer version of the system. But again: this decision needs to be made deliberately, too.

If lib 1.5.2 contains a bug fix from which you know it works for System 2.0.2, but maybe has risks for V2.1.0, you may consider to create a version 1.5.3 first where the bugs are fixed and the risks are eliminated.

Should I create branches (develop, 2.0.0) for the library following the release version as well?

For each release (feature or hotfix, does not matter), there should be a branch containing exactly the components of this branch, otherwise you loose reproducability of reported issues.

Answer 2

My advice would be, "Don't mix branching and versioning"

Code gets a version when you release it. With compiled code its easy to see the demarcation between code and a release, but with interpreted code where you are just copying to a directory people tend to give their code a version and this is where it gets confusing. Does each file have a version? do classes have versions? etc etc

Unless you are releasing your library separately there is no point in giving it a version. your entire program gets a version on release and it goes up by x each time you release.

If you separate your library into a different source control repository then again, your problems are solved. You give it a new number every release, and dependant programs can only use a released version, which they pick.

If you have your library in the same repo as your "main" code and branch for versioning you have a few problems to avoid because you essentially have multiple in progress versions at the same time, you don't know what order they will be released in, or even if they will be merged together into some new version before release.

In this situation I would advise that you only version on master, have only a single version for the entire repo, and version with tags to keep yourself honest.