0

The recommended version strategy in Maven Central Repository is Semantic Versioning 2.0.0, which is pretty strict about how a major version should be affected on any incompatible change (using MUST from RFC 2119 regarding this requirement).

Let's say any method signature is changed, thus a library major version must be updated. That may be happening relatively frequent in libraries that are under development.

That makes me wonder is it actually true for the libraries published in Maven Central, or such a recommendation is not strictly followed?

Community
  • 1
  • 1
Pavel
  • 4,912
  • 7
  • 49
  • 69

2 Answers2

1

SemVer is all about developers conveying the level of effort or risk involved in taking one of their updates. If you make any breaking change and fail to bump the Major version number, you are not following Semantic Versioning 2.0.0 and therefore not following the recommendations of the Maven Central Repository.

It's all about your reputation. Forced re-compiles or cascading upgrades, broken systems that wouldn't have been broken if you followed the rules, these are apparent behaviors that mark a developer's products for replacement. Given the quality of the code floating around out there, I'd say that not following the standards is common enough, but probably not beneficial to anyone, including the lazy bums that fail to meet even the most minimal standards.

jwdonahue
  • 6,199
  • 2
  • 21
  • 43
  • Hi, @jwdonahue, thank you! That's a nice contribution, though it doesn't seem to be related directly to the question about how strictly the recommended convention is actually followed. – Pavel Apr 09 '18 at 03:41
0

No, semantic versioning doesn't seem to be followed rigorously.

The analysis done in a research Semantic versioning versus breaking changes: A study of the Maven Repository concludes:

The introduction of breaking changes is widespread: Around one third of all releases introduce at least one breaking change.

While semantic versioning prescribes that breaking changes are only permitted in major releases, we see little difference between these two: One third of the major as well as one third of the minor releases introduce at least one breaking change.

Moreover, according to the data provided in the article, in 23.8% cases at least one backward incompatible change introduced in on a patch version update.

Pavel
  • 4,912
  • 7
  • 49
  • 69
  • 1
    I had to read that twice to grok it properly. The fact that only 1/3 of Major changes were actually breaking changes, does not imply that SemVer is not being adhered to "rigorously". In fact, the standard allows for Major bumps for any reason the publisher deems appropriate. The fact that ~1/3 of Minor and Patch bumps were breaking changes seems problematic, but it's hardly a majority. That those two last figures are so close in relative magnitude seems to indicate there are number of folks who use a version triple that aren't actually applying SemVer in practice. – jwdonahue Apr 09 '18 at 20:28
  • 1
    Some of those are bound to be errors on the part of adherents as well, so we're probably looking at ~2/3 are at least trying. Based on the numbers stated in your post, I believe your claim that it is not being followed rigorously, is a bit over-stated. What percentage of these libraries contain documentation claiming adherence? – jwdonahue Apr 09 '18 at 20:32
  • 1
    The study conclusions are flawed at best. They include in their statistics, version strings that do not meet the SemVer syntax requirement. By assuming Patch is zero for X.Y style versions, and accepting things like "1.0.D2" they are including intentionally non-conforming libraries in with those that do conform and claiming the entire population fails. As a general rule, any version string that is not syntactically SemVer 2.0.0 compliant, should be treated as if every version is a breaking change. – jwdonahue Apr 09 '18 at 21:28
  • It's a shame that roughly a third of the libraries found do not employ SemVer, as witnessed by their non-conforming syntax, but it may or may not be a coincidence that number is on the relative order of the same statistics you quoted above. – jwdonahue Apr 09 '18 at 21:31
  • 1
    Not one Maven library follows the SemVer deprecation pattern! Mostly, they just don't bother to actually remove deprecated API's. The number of public API's that get deleted is said to be 33.03%, which also happens to be proportional to number of breaking changes found that did not get a Major version bump and suspiciously close to the number of versions in the data set that also did not comply with the SemVer syntax. – jwdonahue Apr 09 '18 at 22:11
  • Hi, @jwdonahue, that's a great analysis, thank you very much! The fact that X.Y style versions are accepted and interpreted as X.Y.0 is somehow arguable approach, indeed. – Pavel Apr 10 '18 at 03:25
  • There are many interpretations of "rigorously". For sure, depending on a perception it may seem a bit over-stated. I said it from a practical point of view, since a chance to just compile a project on minor update is not that big (especially when there are several minor and patch updates). – Pavel Apr 10 '18 at 03:33
  • In my mind the statement `X not Y` is false if there is one X that is Y. Basically, SemVer is followed more or less rigorously by many developers. If you shun non-conforming products, you will likely find the incidence of accidental breakage is fairly low. It would really be interesting to know for instance, how much use the population of non-conforming products actually get. In other words, what percentage of the downloads from the site are non-compliant? I'd be willing to bet it would yield a much lower result, especially today, after SemVer 2.0.0 has had some bake time in the community. – jwdonahue Apr 13 '18 at 16:42