Is there any reason a new public project being started, if given the choice (e.g., not constrained by their company), would use something other than Semver? Are there competing methodologies, i.e., Semver has not been widely accepted yet?
This question arises because a very well known package that I use updated from 3.2 to 3.3. I blindly updated, thinking this could only add new APIs, not break old APIs. And to my surprise, 3.3 deleted some deprecated APIs. Checking their versioning, it did not state what “system” they use.
So, should we assume Semver is the default for [most/all] Github projects?
Edit: semver.org
Edit2: I think this debate greatly depends on whether the software is a library or an end application (the user is sitting in front of it interacting with it). My original intention was to discuss the former. That is, if the code can be a dependency in other code. Non-semver libraries make it very hard to know whether it is safe to download a newer version of the library and depend on it. In contrast, I don’t care what something like the version Firefox is because you aren’t using it as a library, you’re using it as an end application.
6
Semantic versioning is not, AFAIK, an official standard (by some organization like ISO). But they are so many of them that we cannot be sure (and I certainly do not know most of ISO standards).
And some software do not use it. For example, Frama-C is releasing versions which are named after chemical element (e.g. Beryllium; But Magnesium was released in January 2016).
Some software have changed their versioning scheme during their lifetime. A notable example includes GCC (and probably also the Linux kernel): GCC used to number 4.1, 4.2, …. for significant version changes (with patchlevels like 4.1.2 or 4.1.3 for small bug fixes), but now they are using version numbers like 5 or 6 (with 5.3 being a patchlevel).
Some software libraries don’t always have any version number, e.g. libonion (an HTTP server library for C & C++, on github; but it has some git-version-gen script).
(maybe I am wrong, and libonion is perhaps getting versioning info & API)
Linux linker provides symbol versioning. See this.
Some C-callable libraries provide preprocessor symbols guiding the implemented API. GCCJIT uses “symbol tags” like LIBGCCJIT_ABI_2. See also feature_test_macros(7) & autoconf on Linux.
The glib library (in GTK) provides an interesting version information API which could be inspirational.
GCC & Clang have the __attribute__((deprecated)) function attribute to mark functions which are deprecated. C++14 specifies the [[deprecated]] attribute. If you publish a library with a significant user community, you probably would make some functions as deprecated in some release, and remove them entirely only in some future release. Notice that in the C standard, the infamous gets function was removed many years after have been announced as deprecated.
8