Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Semantic Versioning an Anti-Pattern?

surfingthe.cloud

Post reply on HN
Print view View original

61–70 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#61

Post by gravypod »

I'm a big fan of really simple versioning schemes.

   ..
Any version ending in a "0" is stable. IE:

   - 1.0.0
   - 0.1.0
     .....
   - 999.999.0
Whenever you are doing a "release" you have tested every feature fully to make sure the software is up to spec. Whenever you are doing a "rewrite" you can assume that the software's APIs have changed and you will need to readjust compatability (ideally APIs never break but this is one example).

With this you get the following:

   - Is this stable to use in production.
   - What software can work with what other software (looking at the major version it requires)
   - Between which two commits a functionality broke. (If 1.1.157 works and 1.1.158 doesn't then you know commit 158 broke something)
With the author's versioning system:

   - The month, year and # of commit you're on
   - If someone else gave us this code (pr-)
   - If there is active development on the code (dev-)
I prefer the former but I can see some of the benifits of the latter. I'm just more of a fan of using flat and simple numbers and not relying on "dev-", "pr-" and the infinite amount of tags that will follow if you start allowing them.

Re: Is Semantic Versioning an Anti-Pattern?

#62

Post by Groxx »

kaspm wrote: post #60
Groxx wrote: post #49

Earlier quoted context omitted.

Ehhh... at best it argues that it's over-complicated for something that only ever has a single version running everywhere. Like a web service that you control, for which there will never be a way to request "use that old version of the code instead".[1] Which is true. But then why even bother with YYMM.xxxx? Just use a single incrementing integer. Or none - nothing can ever go backwards, so callers are required to ig…

Yeah okay. I think there is a very large group of developers who work in just such an environment: developing web applications that have a "production" version whether they are public internet or internal to companies where the previous version would literally _never_ be consumed. The reason to track a increment in that kind of environment is as a code to align feature requests to a particular release (usually by dat…

Yeah, the blog's context isn't about libraries. And agreed, tons of developers work in environments like this.

I pretty much exclusively deal with SHAs too, since tons of tooling understands it, and there's no implied order just by looking at it - which is a good thing. A SHA might be out, but waiting to ramp up to 100%. It does tend to mean "end of (nearly) all dev work" though, which is the actually important part for day-to-day developing.

Re: Is Semantic Versioning an Anti-Pattern?

#63

Post by thaumaturgy »

taeric wrote: post #54
ryan_lane wrote: post #10

This post completely ignores one of the most important features of semver, which is dependency management. Being able to do this is really great: some-library>=1.0.0, It means I can include a library and get non-breaking changes and all security updates until the next major release without worrying that a change is going to break me randomly. It doesn't mean I don't need to do testing, but it makes it a lot more like…

My biggest beef with semver is that it is pushed by people encouraging this concept that additions are always safe. Or the lie that people will do security and other updates on older versions. By and large, especially in an org, if you make a change that requires another place to change, you should go ahead and make that change. Period. Thinking people can stay on the old version till they want to update is BS. They…

It used to work that way, though; software in the 90s and early 2000s did have sane semantic versioning, updates were backported to earlier major versions, and revision updates generally didn't break anything in production.

I bet semantic versioning is mostly championed by older veterans who have worked in maintenance or systems administration roles and are trying to get the industry to return to a versioning system that made sense once upon a time.

For my part ... while I'd dearly love to see semantic versioning come back, along with a few other good habits from a long time ago, I've given up on that and now just accept that updates will break things sometimes and there's always something to update and so something will be broken most of the time and that's just how it is so charge accordingly.

Re: Is Semantic Versioning an Anti-Pattern?

#64

Post by paulddraper »

ryan_lane wrote: post #10

This post completely ignores one of the most important features of semver, which is dependency management. Being able to do this is really great: some-library>=1.0.0, It means I can include a library and get non-breaking changes and all security updates until the next major release without worrying that a change is going to break me randomly. It doesn't mean I don't need to do testing, but it makes it a lot more like…

> Being able to do this is really great: some-library>=1.0.0,No, no, no, no it isn't great; it's terrible.

It's makes the version used non-deterministic, and that is a recipe for build hell. The whole reason we have lockfiles, shrinkwrap, etc. is because people are specifying version ranges.

Re: Is Semantic Versioning an Anti-Pattern?

#65

Post by rmattes »

extrapickles wrote: post #50

I never really liked semver as its a mixture of release number and an abstraction/categorization of risk that nobody can agree on, making it hard to tell how stable an update will be. It was fine back when you only had a release or two a year, but now the abstraction is no longer good enough. I prefer the first number to be a simple release number, then the second to be the amount of risk from the previous release. T…

What do you mean by risk? How would you quantify it?

As I understand it, all semver is trying to tell you is when backwards-compatible changes happen, and when backwards-incompatible changes happen.

If the project developer wants to add some sort of indication that "this package contains changes that are alpha quality, and may not respect semver for the next few releases" then that developer can append a pre-release identifer to the version, as described in the semver spec. Once that identifier goes away, the risk that a package violates semver should be gone, and you should be free to update based on the semver relation to the previous release.

Ultimately, it's up to the project to verify that their releases don't violate the semver spec by being diligent with respect to their public API. If you find that a project isn't disciplined in documenting API changes (semver or otherwise,) then coming upw ith new rules to convey the information they're already not conveying isn't going to help anything.

Re: Is Semantic Versioning an Anti-Pattern?

#66

Post by flukus »

eridius wrote: post #58

The author seems to be completely missing the boat here. SemVer isn't meant for Continuous Delivery production systems. Why would you even attempt to use it for that? SemVer is for libraries, and specifically for making dependency management easy. If you're not writing a library that gets distributed to other people, then use whatever versioning system you want.

> Why would you even attempt to use it for that?

Can you name a package management tool that doesn't rely on SemVer?

Re: Is Semantic Versioning an Anti-Pattern?

#67

Post by nine_k »

paulddraper wrote: post #64
ryan_lane wrote: post #10

This post completely ignores one of the most important features of semver, which is dependency management. Being able to do this is really great: some-library>=1.0.0, It means I can include a library and get non-breaking changes and all security updates until the next major release without worrying that a change is going to break me randomly. It doesn't mean I don't need to do testing, but it makes it a lot more like…

> Being able to do this is really great: some-library>=1.0.0, No, no, no, no it isn't great; it's terrible. It's makes the version used non-deterministic, and that is a recipe for build hell. The whole reason we have lockfiles, shrinkwrap, etc. is because people are specifying version ranges.

Do you ever update software on your computer?

You may lock library versions for a build pretty strictly. But the more loose is the coupling, the more elbow room you have in this regard, so you can upgrade your ngnix without breaking your wsgi apps, or your database without breaking anything — when done within a reasonable range of versions.

Re: Is Semantic Versioning an Anti-Pattern?

#68

Post by seagreen »

paulddraper wrote: post #64
ryan_lane wrote: post #10

This post completely ignores one of the most important features of semver, which is dependency management. Being able to do this is really great: some-library>=1.0.0, It means I can include a library and get non-breaking changes and all security updates until the next major release without worrying that a change is going to break me randomly. It doesn't mean I don't need to do testing, but it makes it a lot more like…

> Being able to do this is really great: some-library>=1.0.0, No, no, no, no it isn't great; it's terrible. It's makes the version used non-deterministic, and that is a recipe for build hell. The whole reason we have lockfiles, shrinkwrap, etc. is because people are specifying version ranges.

Executables should pin.

Libraries should depend on ranges (though they can also pin internally for development).

Re: Is Semantic Versioning an Anti-Pattern?

#69

Post by AgentME »

paulddraper wrote: post #64
ryan_lane wrote: post #10

This post completely ignores one of the most important features of semver, which is dependency management. Being able to do this is really great: some-library>=1.0.0, It means I can include a library and get non-breaking changes and all security updates until the next major release without worrying that a change is going to break me randomly. It doesn't mean I don't need to do testing, but it makes it a lot more like…

> Being able to do this is really great: some-library>=1.0.0, No, no, no, no it isn't great; it's terrible. It's makes the version used non-deterministic, and that is a recipe for build hell. The whole reason we have lockfiles, shrinkwrap, etc. is because people are specifying version ranges.

You're still allowed to use lockfiles and shrinkwraps.

Anyone deploying an application to a server or distributing an application to end users should have the dependencies shrinkwrapped and the application tested with them.

Upgrading dependencies to get bug and security fixes in minor and point releases is as easy as deleting the shrinkwrap, installing the dependencies again, and making a new shrinkwrap. Then you put your application through all of its tests with the new dependencies, commit the new shrinkwrap, and then you can release/deploy a new version of the application.

Re: Is Semantic Versioning an Anti-Pattern?

#70

Post by fenomas »

Why is it that every time there's an article criticizing semver, the author never seems to have bothered looking at the spec?

> 1. Software using Semantic Versioning MUST declare a public API.

That's the very first thing it says. Semver is not meant for general apps or websites or the like, it's for APIs against which dependencies can be declared.

If your software doesn't need to tell package managers about its compatibility, then it doesn't need semver. Complaining that semver is bad for human readability is like saying hammers are an antipattern because you don't use nails.

Post reply on HN