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.
For some (me included) version numbers are not a tool to demonstrated progress, they are a tool to demonstrated change (breaking change vs non breaking change basically).
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.
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.
I'm on your side, no doubt. You got my up vote, your parent got my down vote, and his parent got my pathetic attempt to up vote back into readability, because I think even poorly phrased references to academic concepts benefit the audience. I absolutely agree with you in principle.
With that said, that post about the "naturalistic fallacy" could just as easily been written "Your intuition is not an argument. What are you really saying about this?" There would have been no wall of text nor any deep explanation. It would have been strictly simpler and clearer.
But if he'd said that, I wouldn't have learned about the naturalistic fallacy, and that would have been a loss. The real problem on the internet is not ivory-tower eggheads, but techies who say the adult equivalent of "I don't like green beans" and expect that to be of general interest or benefit.
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.
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.
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.
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?
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.
It's not really that complicated. I mean, everything is egregiously complicated if you're not willing to meet someone halfway to interpret what they mean in context, and that's the expectation here. The use of Naturalistic fallacy means here whatever it makes the most sense for it to mean.
Ambiguity is not only a problem, it also has significant advantages.
...huh, I had assumed so strongly that it worked like 'normal' x.y versioning that I had to go back and re-read the manifesto to realize that this was how it was intended to work.
That picture wasn't what I was expecting, which was more like this: http://i.imgur.com/Lx6OiIb.png
solid arrows show chronology, the colors highlight compatibility, dashed arrows are backporting.
Why would SemVer encourage releasing backwards-compatible new features more than this? You have just as much motivation to not increase the compatibility number.
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.
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".
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.
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.
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.
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.
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).
>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.
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.
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.
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.
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?
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-). It has between two and three components.
The "mono" this is referring to is "monotonic", specifically "monotically increasing" (https://en.wikipedia.org/wiki/Monotonic_function). That is, when layed out chronologically the components of the version numbers are always increasing.
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.
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.
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.
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.
