
Monotonic Versioning Manifesto - Freaky
http://blog.appliedcompscilab.com/monotonic_versioning_manifesto/
======
bigblind
I think you do lose some information this way. If the release number isn't
reset with every breaking change, you have no context for how mature that
change is. For a library that's very importantto your app's functionality, you
might prefer to use 1.13, instead of 2.1. As the 2.x release number increases,
you can see that version 2 has been iterated upon.

~~~
rbjorklin
I agree! This does not feel intuative at all: 1.1 -> 2.2 -> 2.3 -> 3.4

~~~
DominikD
Naturalistic fallacy informs public about your preferences but doesn't really
tell us anything about the concept itself. :)

~~~
talles
I'm sincerely tired of those comments that uses overly complicated and shady
use of the language to denote simple ideas.

If you were in a middle of a philosophy book and have previously defined what
you mean by "naturalistic fallacy" that would be fine, but you are literally
throwing the term in an isolated sentence.

~~~
badsock
And I'm tired of everything being dumbed down to within an inch of its life -
filled with introductory noise, or worse, just avoiding complex arguments.

We're all reading this on the internet - if you don't know what a term means
it only requires a tiny hand movement and a few seconds to fix that. That way
we can have discussions that build on previous abstractions and move on to
more complex ideas.

It's a shame that the "arrogant ivory-tower egghead" narrative sticks so
easily. It's true that some people use words to obscure, but just as often
it's someone trying to say something that's difficult to explain in any other
way without ending up with a wall of text.

~~~
talles
I'm arguing in favor of simplicity, not of simplicity of reach (tiny hand
movement) but of simplicity of meaning.

Bringing up Hume's guillotine [1] to show someone that version numbers is not
what it seems to be to that individual is a bit of an overkill, don't you
think?

If we start to see everything as Kant's golden rule [2], Sartre's existence
problem [3], Wittgenstein's private language [4] and Marx's worker struggle
[5] is going to be very hard at all to communicate simple ideas, most of time
those are arguments that raises more questions than answers.

To make a programming analogy, is a bit like design patterns, sometimes is
nice to say "it's just a factory" without having to go throughout the concept
of factory, but if you overuse it and start talking only in patterns it all
becomes a mess.

If it's complex, suite yourself. If it ain't, don't make it so.

[1]:
[https://www.youtube.com/watch?v=eT7yXG2aJdY](https://www.youtube.com/watch?v=eT7yXG2aJdY)

[2]:
[https://www.youtube.com/watch?v=x_uUEaeqFog](https://www.youtube.com/watch?v=x_uUEaeqFog)

[3]:
[https://www.youtube.com/watch?v=qpXNRrtuo38](https://www.youtube.com/watch?v=qpXNRrtuo38)

[4]:
[https://www.youtube.com/watch?v=x86hLtOkou8](https://www.youtube.com/watch?v=x86hLtOkou8)

[5]:
[https://www.youtube.com/watch?v=PZ4VzhIuKCQ](https://www.youtube.com/watch?v=PZ4VzhIuKCQ)

~~~
nitrogen
You are introducing ideas named for people, rather than the idea itself. _Of
course_ that will obscure meaning, and you are only further deteriorating the
SNR of the thread by doing so.

~~~
talles
And you didn't like that, right? You felt as being noise to the actual meaning
I'm trying to convey.

Precisely my point.

~~~
nitrogen
No, it comes across as a deliberate tactic, entirely unrelated to the benign
use of "naturalistic fallacy" in the original comment. I feel the actual
meaning you are trying to convey _is_ noise, and you've done so in a way that
is not representative of the original comment.

~~~
talles
Yes, my saying is "deliberate", I'm in full command of my actions and
thinking. And yes, it is a "tactic", after all I'm trying to do something here
(convey a point in an argumentation).

I hope that by "deliberate tactic" you didn't try to imply as being "mean" or
"bad" or not "benign".

As for the "benign use" you mentioned, it is clearly your opinion on it, but
where are your reasons, your arguments in favour of it?

(welcome to the conversation)

~~~
nitrogen
A _deliberately obtuse tactic_. Your point is not well made, and is a waste of
thread space. The arguments in favor of the original comment have been stated
by others. I will not continue replying.

~~~
nitrogen
Hmm. While I stand by the sentiment of this comment, in hindsight I could have
worded it less harshly.

------
neilbowers
That picture wasn't what I was expecting, which was more like this:
[http://i.imgur.com/Lx6OiIb.png](http://i.imgur.com/Lx6OiIb.png) solid arrows
show chronology, the colors highlight compatibility, dashed arrows are
backporting.

------
raziel2p
I dislike this. The reasons I like semantic versioning is that it encourages
things that I consider to be good:

\- releasing features separately from bugfixes

\- releasing backwards-compatible new features

\- releasing bugfixes for older releases (this one is more optional)

This versioning scheme seems to remove all of that just for the sake of
simplicity - I don't see the benefits.

~~~
talles
SemVer does not encourage the things you listed, it only demands that you show
such changes in its versioning.

The difference here with Monotonic is that such changes does not have a
special meaning in the version number (nothing on the encouragment side IMO).

------
ollysb
The patch level allows you to indicate when a release was bad and should be
ignored (you should always use the highest patch release). With monotonic
versioning an unintended breaking change must be corrected by another breaking
change (breaking WRT the broken version). Now you have two breaking changes
where having a patch level would allow you to correct the regression and
continue with no breaking changes in the release history.

~~~
falcolas
The spec encourages the following, if a bad bug is found (cough openssl):

1.1 -> 2.2 -> 3.3 -> 1.4 -> 2.5 -> 3.6

And in fact I kind of like this. 1.4 is rather obviously compatible with 1.1
(and 2.5 with 2.2), but also clearly denotes a new release. You're still
always using the most recent release, within a compatibility number.

Even better, it avoids crap like: "Affected users should upgrade to OpenSSL
1.0.1g. 1.0.2 will be fixed in 1.0.2-beta2." Instead, the fix is announced
simply "Bug fixed in release 4 and later".

~~~
bsimpson
I thought it said explicitly not to do that in the same paragraph:

    
    
      The Release Number SHALL NOT be decremented.
    

Which would break exactly this us case if you followed to a T.

~~~
deckar01
It is confusing, but the release number is never decremented in this example,
the compatibility number is being reused to indicate the release is compatible
the API documentation for the existing compatibility number.

~~~
bsimpson
Damn, that was really confusingly worded.

------
DominikD
World never asked for this. ;) Seriously though - any versioning scheme, as
long as it's consistent, is fine. Like everything in the world, this has some
pros and cons compared to typical semantic versioning: it does remove some of
the noise/confusion in exchange for potentially exploding release number. If
you're releasing often, semver probably makes more sense. If you're releasing
at a glacier pace but break BC from time to time, this looks like a good
match.

~~~
curryhoward
Genuinely curious, what is the problem with "exploding release number"s?

~~~
DominikD
We've had this problem in one of the internal projects in the past where
version would change so rapidly we basically didn't care about some of them.
By the time team A did something to .70 there was already .75 released by team
B. What do you do to, say, .72 - port changes? Ignore it? Does anyone actually
care about in-betweens?

This also increased cognitive load: if I have 5 versions to care about I
actually have better understanding of what went where, why, etc. With hundreds
of versions institutional memory wasn't as strong.

I feel that if we were to push minor updates (ones only team B cared about) to
a separate portion, everyone would be better off. This changed for later
projects and simplified workflow (you could actually remember things).

~~~
Nokinside
>What do you do to, say, .72 - port changes? Ignore it? Does anyone actually
care about in-betweens?

It seems that your project was misusing version management.

Despite the name, version management is not actually taking care of managing
your software versions for your project. It takes care of the bit level
versions, you still need people to manage the semantics and human side of it.

If different groups can push an pull things without anyone accepting,
rejecting and deciding what is release branch and development branch, you are
doing it wrong.

------
talles
There are two very good things about this versioning that people seems to miss
it here on the comment section:

* One, stated in the manifesto itself, is that we don't have the minor and patch distinction anymore. Let's be honest, most of us (but not all) simply doesn't care if the library update is a minor or a patch, we are only scary of the major number.

* The second is that with Monotonic you have a sense of ordering of the whole project (note that I'm saying order, not progress). If I give you two different SemVer version numbers are you able to say which one was released first or how old they are? With Monotonic you can answer that, the RELEASE number is common to all COMPATIBILITY "branches".

I have to say, I liked it. But I guess it won't be adopted by many since
SemVer is somewhat ubiquitous and is entrenched in the how we think version
numbers.

~~~
DougWebb
As the author of a library, I care _very much_ about the minor and patch
numbers: when you report a bug to me, I want to know exactly which build
you're using. But I don't want that to impact the major/minor release number,
which document compatibility.

Eg: releases 2.4.0.0, 2.4.1.4, and 2.4.0.3, are all equally compatible and
have the same API. They are all version 2.4, and any software that uses them
only needs to express a dependency on v2.4. But they're all different builds
with internal changes (that don't alter the API), and if you report a bug I
need to know which of those builds you're using.

If they were numbered 2.4, 2.5, and 2.6, I guess I'd know the build, but I'd
lose some flexibility in expressing the API compatibility. I like being able
to say that anything which works with 2.x will also work with 2.x+, where 2.x+
might add features but will not remove them. However, 3.0 might remove API
methods or alter the semantics of existing methods. A single compatibility
number doesn't let you express that.

------
alexatkeplar
Really interesting. I like the way that the total ordering approach makes it
clear when an earlier compatibility-version (e.g. 1._) is being maintained
alongside a later version (e.g. 2._). That's something that isn't expressible
in SemVer.

~~~
patal
Do you mean instance where the release number be the same, as in 1.77 vs.
2.77? Because that likely won't happen, as due to the different compatibility
these should be different releases. Or do you mean, if the release numbers are
reasonably close, as in 1.77 vs. 2.78, and then maybe 1.79 again?

------
mitchtbaum
HTML progresses without using version numbers. Perhaps, in general, we don't
need them..

[https://blog.whatwg.org/html-is-the-new-html5](https://blog.whatwg.org/html-
is-the-new-html5)

~~~
jacques_chester
We care about version numbers of _browsers_ , because in practice those
numbers encode what HTML, CSS and JavaScript is available.

------
lucb1e
The requirement of a public API seems weird to me. What is the point of that;
why should my versioning scheme meddle with whether I want to release an API?

Also a small note on the name, I don't see how `4.7944+beta7` is
"MonoVer/MVer/MoVer" since it's not quite... mono
([http://www.dictionary.com/browse/mono-](http://www.dictionary.com/browse/mono-)).
It has between two and three components.

~~~
sephlietz
The "mono" this is referring to is "monotonic", specifically "monotically
increasing"
([https://en.wikipedia.org/wiki/Monotonic_function](https://en.wikipedia.org/wiki/Monotonic_function)).
That is, when layed out chronologically the components of the version numbers
are always increasing.

~~~
solipsism
Technically, "never decreasing" is more correct than "always increasing",
regarding "monotonically increasing". In MonoVer the Compatibility number is
monotonically increasing but not always increasing. The release number is
both.

------
jacques_chester
I've seen a scheme like this used for numbering BOSH stemcells and
releases[0]. If you have slow-changing or update-in-place artefacts like
sourcecode it will look a bit like a shortened semver.

If, as is the case for BOSH, you are meant to totally replace the previous
version, then the numbers advance rapidly. Note that stemcell versions are
into the low 3000s.

[0] [http://bosh.io/](http://bosh.io/)

