

Break Versioning (BreakVer) - reedlaw
https://github.com/ptaoussanis/encore/blob/master/BREAK-VERSIONING.md

======
chton
I think this is a bad, bad idea. While SemVer is not by any means perfect, the
arguments you give for abandoning it are either in SemVer by design or a
matter of time.

In order: 1\. A 'breaking change' in SemVer is a change where the API was
changed. Code that was built against a previous version will now fail to
build. It does not mention behaviour in any way, only the exact contracts your
software correspond with. As such, there are no 'major' or 'minor' changes.
It's either a breaking change or not a breaking change. The minor versions in
SemVer are for additions that don't break the API but add to it, and so do not
constitute breaking changes.

2\. Psychological influences are a matter of time and saturation. SemVer is
more and more widely used, but the psychological element you say is mostly an
artifact of the random way versioning was done before it. Over time, and with
further adoption of SemVer, people will be less afraid of upgrades and in
general more sensible about it. This is an effect of the improved
predictability of what a bump in what version number implies.

3\. Code is supposed to linger for a decent time in <1.0.0. Version 1.0.0 is
the first version that has a defined API that is guaranteed to be there until
2.0.0, so software naturally takes a long time to stabilize enough for that to
be possible.

[1] Since SemVer only demands a bump in the major version if the actual API
changes, most packages won't go through a lot of them. In general, a product
that has reached some level of maturity will have a stable API, for the
benefit of the programmers and the consumers alike.

My biggest gripe with your versioning system, however, is that it's not cross-
compatible with SemVer. You're introducing an alternative that does not work
in the same way, is not easily distinguishable from SemVer, but can break my
code after an upgrade. What if I think your package works with SemVer, and so
upgrade to a new minor version thinking it's fine and the API wasn't broken?
Suddenly, I've got a version of your package that does break, and I've got a
lot of work to undo the upgrade. At worst, I don't notice the breaking until
it's already running in production and Bad Stuff Happens.

I'm fine with criticizing Semantic Versioning, and you're free to find your
own alternatives, but they should be cross-compatible with SemVer or very
easily distinguishable. Using the same syntax to signify a completely
different semantic is a recipe for disaster.

~~~
reedlaw
I'm not the author, but I think this idea, as well as Jeremy Ashkenas'
reaction to SemVer, both try to address the underlying assumption that all you
need is a version number to know if you should upgrade. First, in practice
there are too many packages that don't adhere to SemVer, or appear to do so
but in reality are not sufficiently tested for SemVer to be of any use.
Second, if your code depends on any package, you are ultimately responsible
for every potential breakage whether due to upgrades, security flaws, or bugs.
Of course no one can control everything, but SemVer can give a false sense of
security. Personally I prefer to look at a changelog because it has a lot more
detail than a version number can ever convey.

~~~
chton
I agree that the 'false sense of security' problem is one of the biggest
issues that SemVer faces, but it can be remedied in a variety of ways. Nuget,
for example, is strongly focused on SemVer, and most (recent) packages tend to
follow it. It's a cultural issue more than a technical one.

It's also very true that the responsibility is on the developer doing the
upgrade, but the package maker should not make that job harder or more risky
than it already is. Creating hard-to-distinguish variations that can have a
big impact is not a good way to make upgrades easier.

