Versioning scheme and pkg-config

[christoph-conrads]

For the development releases of OpenBLAS 0.2.20, the designation 0.2.20.dev was chosen. The problem with this numbering is that pkg-config recognizes this version as being at least as recent as 0.2.20:

christoph:~$ pkg-config --print-errors --atleast-version=0.2.21 openblas
Requested 'openblas >= 0.2.21' but version of openblas is 0.2.20.dev
You may find new versions of openblas at https://github.com/xianyi/OpenBLAS
christoph:~$ pkg-config --print-errors --atleast-version=0.2.20 openblas
christoph:~$ cat /usr/local/lib/pkgconfig/openblas.pc 
libdir=/usr/local/lib
includedir=/usr/local/include
version=0.2.20.dev
extralib=-lm -lpthread -lgfortran -lm -lpthread -lgfortran
Name: openblas
Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version
Version: ${version}
URL: https://github.com/xianyi/OpenBLAS
Libs: -L${libdir} -lopenblas
Libs.private: ${extralib}
Cflags: -I${includedir}

I would like to ask you to change the versioning scheme such that one can filter pre-releases with the aid of the pkg-config version number.

One possibility is to use odd version numbers for development releases and even version numbers for stable releases. A brief list of open source projects who (used to) use this versioning scheme is here: https://stackoverflow.com/questions/1266411/which-open-source-projects-use-odd-unstable-even-stable-style-of-versioning

[martin-frbg]

Probably easier to just use something like 0.2.19.1 instead of 0.2.20.dev for the entirely temporary naming of "development version leading up to 0.2.20" instead of playing the odd-even game ? Not everybody uses pkgconfig at all...

[christoph-conrads]

The odd-even scheme is just a suggestion and I edited my post to clarify this point.

[brada4]

There is no API change between versions and no need to require particular number. Maybe lapack (if and which) included could matter as a version.

[martin-frbg]

Revisiting this issue, I am not even sure now if your example actually shows a problem - any "0.2.20.dev" is at least as recent as "0.2.20", but will not have all the features of "0.2.21" except for a very short time around the release date of the latter. And what of 0.2.21 is already in a 0.2.20.dev snapshot from any given day is pretty much undefined. So your suggestion would work for the special case that something important was added immediately after a release, but in general it would appear to require an unwieldy numbering scheme where the last digit needs to be incremented with every commit. (Shorter release cycles would certainly help, but as #1258 seems to show there is little that can be done when "real life" gets in the way)

[christoph-conrads]

I would like to have a versioning scheme where

• stable releases and pre-releases have different version numbers
• where more recent versions have higher version numbers than older versions.

Naturally, no ones wants to change the version number with every commit. Hence, we can assume that there will be multiple commits with version number 0.2.20.dev. The last commit with this version number may be feature-identical to version 0.2.20.

When I want to use OpenBLAS' pkg-config information, then I have the following problem: Version 0.2.20.dev refers to multiple commits and the version installed on the system may not have the features that I am looking for. Thus, I would like to have different version numbers for releases and pre-releases exactly to avoid the need to increment the version number with every commit. Since version 0.2.20 is more recent (albeit maybe identical otherwise), I would like to give it a higher version number than the 0.2.20 pre-releases.

[brada4]

Variable features are only in LAPACK side of things, probably that can be added as retrievable version number additionally

[martin-frbg]

Methinks the "variable features" he is looking for is any new functionality, and the current "dev" suffix does not allow pkgconfig to differentiate between (any) snapshot before a given release and the release proper. (in his example above, apparently "0.2.20.dev" is treated as equivalent to the final 0.2.20). Perhaps the main question is who intends to package such snapshots at all, and if they do will it be done in the belief that the snapshot is as good as the upcoming release as far as the packager is concerned ? (But if we change the scheme, perhaps the easiest would be to just delay incrementing of the version number, so "0.2.20.dev" would become "0.2.20 plus some goodies" instead of "some goodies that will eventually make 0.2.20")

[christoph-conrads]

Perhaps the main question is who intends to package such snapshots at all, and if they do will it be done in the belief that the snapshot is as good as the upcoming release as far as the packager is concerned ?

OpenBLAS already has a versioning scheme where development commits have version numbers different from releases and this issue is a request to slightly modify your existing versioning scheme so that functionality built into pkg-config can be used.

I do not expect pre-releases to be as good as the following release but I have to build software for Android devices with ARMv7 CPUs and soft-float ABI. Until a few weeks ago, I had a very good reason (see #1215) to use the latest git commits. After version 0.2.20 was released, my new priorities were to use a stable OpenBLAS release with version 0.2.20 or newer.

"0.2.20.dev" would become "0.2.20 plus some goodies"

I think you meant

"0.2.20.dev" would become "0.2.19 plus some goodies"

[brada4]

it could as well be removed to mimick netlib blas

[martin-frbg]

"0.2.20.dev" would become "0.2.20 plus some goodies"

I think you meant

"0.2.20.dev" would become "0.2.19 plus some goodies"

No, that is what we have now - number of next version plus appended ".dev" - appending the dev to the number of the last stable version would at least match pkgconfig's interpretation of it being "at least as new" as that one. But I am not actually arguing for that change - anybody who uses a daily snapshot should be aware of that, and anyone actually wanting to package it for some distro might as well patch the version number to reflect the git hash or the date.

[brada4]

pc file is missing build configuration altogether, like presence of BLAS, CBLAS, LAPACK, LAPACKE. There is no value at all requiring minimal version when you dont know what you get back.