7 ms·

Monotonic Versioning Manifesto

103 points by Freaky 10y ago

DominikD 10y ago
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 10y ago
  Genuinely curious, what is the problem with "exploding release number"s?
  - DominikD 10y ago
    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 10y ago
      >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.
  - deleted 10y ago
    [deleted]
- vinceguidry 10y ago
  > World never asked for this. He did call it a manifesto. That's the whole point.
bigblind 10y ago
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 10y ago
  I agree! This does not feel intuative at all: 1.1 -> 2.2 -> 2.3 -> 3.4
  - DominikD 10y ago
    Naturalistic fallacy informs public about your preferences but doesn't really tell us anything about the concept itself. :)
    - talles 10y ago
      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 10y ago
        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.
ollysb 10y ago
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.
- sjrd 10y ago
  Well, in SemVer or Monotonic Versioning, if you make an unintended breaking change, say in version 2.3, you've already broken your versioning scheme anyway. So it does not really matter whether your fix (which is incompatible wrt. the broken version) is published as 2.4. The best you can do in those situations is to advertise as publicly as possible that version 2.3 should never be used.
  - pskocik 10y ago
    I believe that's what the patch number does in semver (M.m.p). For a constant M.m, you want maximum(p) as there's potentially something wrong with any p that's less than maximum(p). Monotonic versioning seems to want to move this deprecation information to a separate channel.
- falcolas 10y ago
  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 10y ago
    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.
alexatkeplar 10y ago
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 10y ago
  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?
raziel2p 10y ago
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 10y ago
  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).
- solipsism 10y ago
  Why would SemVer encourage releasing backwards-compatible new features more than this? You have just as much motivation to not increase the compatibility number. releasing bugfixes for older releases Good point. The "manifesto" should mention this.
mitchtbaum 10y ago
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
- kzrdude 10y ago
  Do we know enough yet to draw conclusions from this experiment?
- talles 10y ago
  But what about all the specs that composes HTML? Are they evergreen too?
- jacques_chester 10y ago
  We care about version numbers of browsers, because in practice those numbers encode what HTML, CSS and JavaScript is available.
- colejohnson66 10y ago
  The date of the spec can be thought of as a version number.
lucb1e 10y ago
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 10y ago
  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 10y ago
    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.
- ajanuary 10y ago
  Without a defined public API, you don't have any way of determining if a change is breaking or not, and hence you don't know when you should bump the compatibility number.
- solipsism 10y ago
  Public doesn't necessarily mean "outside my company" or "seen by anyone but you". It refers to the interface available to users (human, if it's an application, or other packages, if it's a library). If it doesn't have a public API it's not usable by anyone and you can save time by not working on it anymore.
talles 10y ago
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 10y ago
  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.
jacques_chester 10y ago
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/
neilbowers 10y ago
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.

103 points by Freaky 10y ago

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 10y ago
Genuinely curious, what is the problem with "exploding release number"s?
- DominikD 10y ago
  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 10y ago
    >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.
- deleted 10y ago
  [deleted]
vinceguidry 10y ago
> World never asked for this. He did call it a manifesto. That's the whole point.

bigblind 10y ago

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 10y ago
I agree! This does not feel intuative at all: 1.1 -> 2.2 -> 2.3 -> 3.4
- DominikD 10y ago
  Naturalistic fallacy informs public about your preferences but doesn't really tell us anything about the concept itself. :)
  - talles 10y ago
    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 10y ago
      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.

ollysb 10y ago

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.

sjrd 10y ago
Well, in SemVer or Monotonic Versioning, if you make an unintended breaking change, say in version 2.3, you've already broken your versioning scheme anyway. So it does not really matter whether your fix (which is incompatible wrt. the broken version) is published as 2.4. The best you can do in those situations is to advertise as publicly as possible that version 2.3 should never be used.
- pskocik 10y ago
  I believe that's what the patch number does in semver (M.m.p). For a constant M.m, you want maximum(p) as there's potentially something wrong with any p that's less than maximum(p). Monotonic versioning seems to want to move this deprecation information to a separate channel.
falcolas 10y ago
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 10y ago
  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.

alexatkeplar 10y ago

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 10y ago
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?

raziel2p 10y ago

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 10y ago
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).
solipsism 10y ago
Why would SemVer encourage releasing backwards-compatible new features more than this? You have just as much motivation to not increase the compatibility number. releasing bugfixes for older releases Good point. The "manifesto" should mention this.

mitchtbaum 10y ago

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

kzrdude 10y ago
Do we know enough yet to draw conclusions from this experiment?
talles 10y ago
But what about all the specs that composes HTML? Are they evergreen too?
jacques_chester 10y ago
We care about version numbers of browsers, because in practice those numbers encode what HTML, CSS and JavaScript is available.
colejohnson66 10y ago
The date of the spec can be thought of as a version number.

lucb1e 10y ago

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 10y ago
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 10y ago
  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.
ajanuary 10y ago
Without a defined public API, you don't have any way of determining if a change is breaking or not, and hence you don't know when you should bump the compatibility number.
solipsism 10y ago
Public doesn't necessarily mean "outside my company" or "seen by anyone but you". It refers to the interface available to users (human, if it's an application, or other packages, if it's a library). If it doesn't have a public API it's not usable by anyone and you can save time by not working on it anymore.

talles 10y ago

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 10y ago
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.

jacques_chester 10y ago

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/

neilbowers 10y ago

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.