Versioning of programs as dependent on library

Question

I have a set of programs, each one with its own version. All these programs are dependent on a library, again with its own version. For example

Foo-1.0.3
Bar-2.1.5
Baz-1.3.4

They depend on libfrobniz-1.4.5. It happens that I have to do a major overhaul of the library (involving a lot of refactoring). This means that it will break everything (Foo, Bar and Baz). Of course, since this is a major and backward incompatible rework, the library will be bumped up to libfrobniz-2.0.0.

My question is relative to the version of Foo Bar and Baz. I will upgrade them to use libfrobniz-2.0.0, but I am not changing their functionality. The new versions of these three programs can be used exactly as the old ones and they are, therefore, fully compatible. However, they will be dependent on a completely different version of libfrobniz. Would you suggest to bump their version major number, or just the patchlevel ?

Answer 1

Remember that changing the major number of the dependency is a major change for the end users. It's definitely not patch level, and I'd say stick with major unless you have a very good reason not to.

Answer 2

I would keep the version numbers of Foo, Bar and Baz the same. Since you are not introducing new features or bug fixes to these user facing products there is no need to bump the version numbers. Furthermore if you do decide to bump the version numbers it could cause user confusion. Your users may wonder why your products have a new version version number without any new documented features or bug fixes.

Inside your three user-facing apps you could have a pane/window that notes that the product relies on libfrobniz and that it has been upgraded.

Answer 3

Your versioning scheme depends of your business and technical needs.

Some companies release "major" upgrade every year to get attention and some income for upgrades. Some of them still release betas, until satisfied with the software quality.

Prepare your own scheme and let your customers know it. Typically first letter is a main version numer for major changes, then for improvements, and then for builds and patches.

Answer 4

Wouldn't this be the same as building a 32bit vs 64bit version of the library? 32bit depends on 32bit libs, while the 64 depends on 64bit libs.

Follow the rules you would use for something like that

Answer 5

"Of course, since this is a major and backward incompatible rework,"

I remember the time when customers had the power to bring any of their software suppliers close to bankruptcy if that software supplier had the nerve to break backward compatibility, by refusing to spend any money until backward compatibility was restored.

The software suppliers always conceded.

Today, it seems like they can do whatever they want, and every customer will just brainlessly follow them, a bit like the lowest class people from "1984".

But perhaps I'm over-pessimistic.

EDIT

Someone pointed out the case where there is only one customer, MySelf. In that case, I wouldn't expect there to be any need for "versioning". Such a customer is interested in exactly one single thing : that the software works, and is interested in exactly one single version : the one that supposedly corresponds to his most recent specs.