2

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.

closed as unclear what you're asking by user22815, gnat, Ixrec, Andres F., Mason Wheeler Apr 14 '16 at 14:28

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 13
    For a random project found on Github, I wouldn't assume anything. – 5gon12eder Apr 14 '16 at 2:43
  • 3
    By "Semver", I assume you mean "Semantic Versioning?" If it's a standard, it's a defacto one; I don't know of any governing body that enforces such a standard, nor is there any way to force people to write their code in a way that does not introduce breaking changes within major versions. – Robert Harvey Apr 14 '16 at 2:44
  • 4
    Worth noting: Deprecated API's are so deprecated precisely because they're not guaranteed to survive in future versions of the software. The developer of the software in question apparently decided that they'd provided adequate warning by deprecating the API that was eventually removed, though I do agree that he should have changed the major version before removing the deprecated API. – Robert Harvey Apr 14 '16 at 2:50
  • 2
    @RobertHarvey: In fact, I, as a user, would even take deprecation as a promise to not burden me with obsolete code. I get frequently annoyed, for example, that the Java 8 JRE still contains methods and classes that have been marked as deprecated since Java 1.2, I believe. Why do I have to download that code? Why do I have to have such old, unused and thus probably less well-maintained and less rigorously security-reviewed code on my machine? – Jörg W Mittag Apr 14 '16 at 9:50
  • @RobertHarvey I would have been totally OK with removing all deprecated APIs in 4.0. – Tommy Apr 14 '16 at 11:35
4

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.

  • 1
    and don't forget Google Chome that introduced the nonsense versioning system of a single ever-increasing number. – gbjbaanb Apr 14 '16 at 7:34
  • 3
    Nah. GNU less did that long before Google even existed. The current version is 481. – Jörg W Mittag Apr 14 '16 at 9:47
  • 1
    Just another random example: The Rubinius project's versioning scheme, its release process, and a comment on the former two (quote: "The Rubinius versioning scheme is emphatically not SemVer."). Another example: Rakudo's current release is Rakudo* (Rakudo Star) 2016.01, which includes Rakudo 2016.01.1 which … – Jörg W Mittag Apr 14 '16 at 10:00
  • … implements Perl v6.c. – Jörg W Mittag Apr 14 '16 at 10:00
  • 2
    And of course there is TeX, which has a version number that converges to pi (the most recent version is 3.14159265). – RemcoGerlich Apr 14 '16 at 11:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.