46 ms·
I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by conventi
by DEADB17 10y ago
I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
I got the impression that the issue was maven not being able to handle multiple versions of the same package/artifact, not in the convention.
- auganov 10y agoHis core opposition is to introducing breaking changes under the same namespace. SemVer is the leading scheme that sanctifies such practice.
- jjnoakes 10y agoPerhaps, but he repeatedly claimed that the minor and patch numbers conveyed no meaning, while dismissing the semver spec as a manifesto. But if he read and understood it, he'd know those were important numbers. Maybe moreso than the major version. Perhaps he should have argued his actual stance more, instead of the strawman stance. That put me off.
- sheepmullet 10y agoFrom the point of view of a library consumer why should they care about the patch or minor versions at all? Isn't later = better?
- jjnoakes 10y agoBecause if you start relying on something new or fixed in x.2.z of your dependency you want to make sure anyone using your code isn't using x.1.y.
- sheepmullet 10y agoAnd doesn't automatic dependency resolution make this a non-issue for your consumer? Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies. It doesn't work this way in Java world due to technical limitations, but it can in JS world
- prodigal_erik 10y agoThat limitation is healthy. If versions 1.1 and 1.2 of a class exist and I'm foolish and determined enough to use both in the same process (via multiple classloaders), Java will still ensure that I can't accidentally give a 1.1 instance to a callee expecting a 1.2 instance, or vice versa. Version mismatches at call sites fail quickly and loudly with classloading exceptions. I think a hell of a lot of NPM packages only appear to work by accident, and over time they'll fail because of sloppiness about this.
- jjnoakes 10y agoConsumers may want to use a different version. Perhaps they want a newer one (bug fix, security fix). Perhaps they want an older one (since another dependency was tested against an older version of the dep in question). Semver gives you a way to decide what ranges of versions should be safe to move between in order to satisfy all of those occasionally conflicting requirements.
- sheepmullet 10y agoExplicitly limiting your consumers to a specific version of another library is a breaking change. You have introduced a very specific dependency and are requiring the consumer to honour it. By semvar rules you should be updating the major version?
- jjnoakes 10y agoWhat? If my library requires X version 1.2 or higher, how is it a breaking change if I don't work with version 2.0 or 1.0 or anything except 1.2 through 1.99999? That's the whole point of software versioning, no matter what you call it (renaming things, semver, git hashes, anything). At some point you require something of someone else, and you can only use the versions of that other library which provide what you require (or more). Semver is just a way to lock those requirements into a machine-readable number scheme.
- DEADB17 10y agoWouldn't changing the MAJOR version be equivalent to changing the namespace without altering the human memorable identifier of the package? Understanding that changes in MINOR.PATCH are backwards compatible, is the difference between NAME MAJOR.MINOR.PATCH and NEW_NAME MINOR.PATCH significant? They look to me as just two different conventions.
- taeric 10y agoNo. Because I don't have a way to keep the old and the new. That is, the point is that you didn't change my use of the old. You just changed what I actually use. It may work. It may not. This is especially egregious when I had to up versions to get some new functions, and old versions just happen to have changed.
- DEADB17 10y agoI don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.
- taeric 10y agoThat is the point. It doesn't convey intent. Outside of the "major versions could break." Which is somewhat worthless. Consider, you are using a library that expose ten objects and functions. It is on version 1.2.8. it upgrades to 1.2.9. What do you do? You take the upgrade. Usually no questions asked. It upgrades to 1.3.0, but only to add an eleventh function. What do you do? Probably take it, because you don't want to be behind. It upgrades to 2.0. reason is "things have changed.". However, they kept the same function names. You think you can make the upgrade fine. Because, well they have the same names. However, you can't know, because some body thought it wise to reverse arguments of some functions. Which thankfully, is a compile time fail. What else changed, though?
- DEADB17 10y agoSorry @taeric, I can't reply to your post directly. I do think that the intent of the producer is being communicated (unsafe to upgrade, safe to upgrade with new features, safe + automatic improvements). I'm not disagreeing that "spec" adding more metadata to have better granularity and potentially reducing the amount of manual work is a good thing. But in the absence of it, "semantic versioning" is an improvement over safe and unsafe versions being indistinguishable.
- sheepmullet 10y agoLike Rich mentioned from the point of view of a library consumer it's: PATCH: Don't care MINOR: Don't care MAJOR: You're screwed MAJOR is simply not granular enough and MINOR and PATCH are pointless. Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems. Did you break one thing I didn't even use? Update the MAJOR version. Did you completely change the library requiring all consumers to rewrite Update the major version.
- jjnoakes 10y agoStill don't see the big problem. If the major version is updated and it doesn't affect you, you have a 10 second job to do. If it does, you have a bigger job to do (or don't update). What's the big deal?
- sheepmullet 10y agoHow do you know if it's a 10 second job or a bigger job?
- jjnoakes 10y agoRead the release notes? Read the code diff? Try it?
- sheepmullet 10y agoSo lots of manual work. And you still don't see the issue? Wouldn't it be good if there was some kind of automated way to know?
- MrBuddyCasino 10y agoThe JVM can't handle multiple versions of the same jar, as there is only one classpath. A depends on B and C, which in turn depend on incompatible versions of D. Congrats, you're screwed, unless you're running in an OSGi container. The only reason this seldom a problem in Java land is because many popular core Java libs, including the whole frickin standard library and all the official extended specs like servlet maintain backwards compatibility, and the successful core libs do too (Guava, commons-whatever). They do what he preaches. Bam, successful platform!
- taeric 10y agoGuava is actually a bad actor in this regard. To the point that it can sometimes teach people that "coding fearlessly" is an wonderful thing. It certainly can be. Especially in monolith code bases where you can fix everything you broke. As a platform, though, it is very frustrating.