3 ms·

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 w

by 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.

by talles 10y ago

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.