Which version number scheme to use when temporarily extending an open source tool?

Question

Assume I want to change an open source library and use it in more than one project, e.g. company C uses library L version 1.0 with license apache-2. The company actually uses a fixed version of it. They send the fixes to the original developer of L but want to use the fixed version before there is an official public version.

The license should allow this. But which version number to use on the temporarily fixed L.

• 1.1?
• 1.0.1?
• 1.0.temp.1?

or something different?

The idea is that there is eventually an public new version and the company should be abel to use it by just changing the version number.

Answer 1

I would rename the package for internal use. Maybe ourL or something like that.

Another way is what someone else did: A friend of mine patched mpg123 in a time it was only barely maintained and called his fork mpg123-thor. He included everything from upstream but with his own patchsets. Now these patches are all in the current mpg123. His patchset based on mpg123-0.59r he called mpg123-0.59r-thor6 (sixth version of the patchset). http://thomas.orgis.org/mpg123-thor/

Answer 2

You don't want to have any conflict or confusion about the version, thus you should use a number that won't cause any. And you can achieve that adding a further sequence to version numbers.

eg: If the project numbers the version based on

1. two sequences (eg. 1.0, 1.1), I would number it 1.0.1;
2. three sequences (eg. 1.0.2, 1.2.0), I would number your version as 1.0.2.1;
3. four sequences (eg. 1.0.3.2, 1.2.4.2), I would number your version as 1.0.3.2.X, where X is one or two letters not among A (alpha), B (beta), F (final), R (release), RC (release candidate), a dash and a number. You could use for example IR (internal release) or SP (submitted patch) or CP (candidate patch).

Nothing prevents you to add a sequence even for an existing four (or n-th) sequences versioning schema, however you should try to make it easy to use it, and allow people share that information cleanly.

Answer 3

I would go with 1.0.1

However, the answer depends on the versioning scheme used by the upstream library L maintainers and your package manager (e.g. RPM, Debian, etc), if you are using one.

If the upstream library maintainers use the versioning scheme a.b.c, then I would add an additional field to make it a.b.c.D. That way you will never have a local version conflict with an upstream version. Also take into account, if applicable, how your package manager determines which version is greater.

The Yocto Project, which helps build embedded Linux distributions, seems to typically add a dash and version at the end for downstream changes.

For example, the upstream package/library version is 1.0. You patch the package wit Yocto and update the version from 1.0 to 1.0-1. In the case of Linux library file names, I would name it /lib/yourlibname.so.1.0.1 since dashes in library file versions is not very common.

Answer 4

I personally use this approach:

1. I check what is the versioning scheme used by the project I patch
2. I collect the version number I am patching
3. I check what is (or what will be) the likely next version number after the one I will patching
4. I create a new version using the scheme used by the project such that it will be resolved as a version after the current and before the next version, eventually tagging it as being a "patched" version with a "patch-1", "patch-2" trailing qualifier if this works out ok for the project versioning scheme

In general, I am not renaming the project packages nor their namespaces otherwise to ensure that --if and when-- my patch is integrated in a future version I can just use again the standard version without any code changes.

... unless I want to release this patched version on a public package repository (e.g. Maven, Rubygems, Pypi, etc) in which case I keep the code and namespaces as-is and I create a new package name typically by prefixing or suffixing the package name with my name, project, company or something differentiating.

As a side note, the Apache 2.0 allows this but also requires tracking changes as described in section 4) Redistribution:

(b) You must cause any modified files to carry prominent notices stating that You changed the files; and ...