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

171–180 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#171

Post by kelnos »

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…

For a smaller org, sure, especially if you have a monolithic build that would break if you made a change like that.

For a larger org, it's basically impossible to do that if you want to make forward progress.

But very much agreed that it's usually not easy to upgrade farther down the road when many things have changed. I've been trying to spread a culture of forethought and not changing things for the sake of "making things pretty", but it's an uphill battle.

Re: Is Semantic Versioning an Anti-Pattern?

#172

Post by Confusion »

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.

Having a non-deterministic version when you build is terrible. So don't do that. Having deterministic build dependencies is also a goal, but a different goal.

Having a non-deterministic version, so you can easily upgrade all your dependencies and get the latest and greatest compatible version of everything, is great.

Re: Is Semantic Versioning an Anti-Pattern?

#173

Post by ZoFreX »

Piskvorrr wrote: post #162
c3534l wrote: post #6

> the labyrinthine process used in Renaissance Italy to elect a Doge I was very disappointed to learn that Italy did not, in fact, elect a Shiba Inu to office.

And worse, this process concerned only the Serenissima (i.e. the area ruled by Venice), not the entire Italy.

The comparison doesn't really make any sense - in what way is the Doge election protocol comparable to semver? It also seems weird to call something bad by comparing it to an election protocol that has been shown to be incredibly robust and was used in a prosperous city state that was successful for a very long time.

Re: Is Semantic Versioning an Anti-Pattern?

#174

Post by stymaar »

stormbrew wrote: post #117
fenomas wrote: post #115

Earlier quoted context omitted.

Er, I don't know anything about rust but cargo is a package manager, right? And the version field you're referring to is what will get checked if someone declares a dependency against your package, right? And you're saying semver makes little sense for that?

Yes, cargo is the package manager, but it is also the build tool. Whether it's a library or a terminal project (one that has nothing depending on it) you use cargo to build it and it has a Cargo.toml. Even if nothing will ever use your package you will always have to have a version field defined in it.

I agree with you, semver doesn't make sens for every project. But it still make sense for a lot of executables, and not only library, let me illustrate that.

Let say you create a cli tool, with a given set of command-line parameters. These parameters are the API your programming is exposing. I can use your program from a shell script for instance, and I will use the existing interface. If, in the next release, you change the options your cli program is accepting, you are actually breaking compatibility with existing integrations including my shell script. Hence this is a breaking change and you should upgrade the major version.

Re: Is Semantic Versioning an Anti-Pattern?

#175

Post by jstimpfle »

flukus wrote: post #120
viraptor wrote: post #108

Earlier quoted context omitted.

I don't do C++ normally, but the situation seems similar. There's http://wiki.c2.com/?PimplIdiom for opaque objects, so you don't have to make their members part of the public API. But for things you do want to make public it's the same solution - make it a your public API by documenting it. If you know it breaks compatibility, it requires major version bump. And no, after compilation, I don't believe the symbol orde…

The pimpl method looks like it ads a level of indirection to every private member access. Is that an issue in practice?

It's an issue if the methods on that object are short-lived enough that the overhead of indirection is significant.

It's also an issue if very performance-sensitive routines need to read data from the object. In which case they already know exactly what's in there, so "pimpl" hiding has no benefit in the first place.

Implementations should be hidden if they are likely to change. In other words, there are are non-obvious data or method members and/or it's likely that functionality will be added in the future. These are the high-level architectural situations, not the leaf level ones where you optimize out every cyle possible.

Re: Is Semantic Versioning an Anti-Pattern?

#176

Post by eeZah7Ux »

thaumaturgy wrote: post #63
taeric wrote: post #54

Earlier quoted context omitted.

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…

A lot of people are still doing that, including Linux distributions. Keeping earlier major versions alive and backporting security fixes is very useful.

Re: Is Semantic Versioning an Anti-Pattern?

#177

Post by pjc50 »

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…

> Thinking people can stay on the old version till they want to update is BS. They will update when they have to.

You can just about get away with this within an organisation, but you cannot do it to your customers if you have a competitor which doesn't impose this workload on them.

I'd like to kill off a decade-old toolchain I have to target, but people are still using the hardware it's required for. They don't want to spend the money on replacements when the current hardware still works, and why should they?

Re: Is Semantic Versioning an Anti-Pattern?

#179

Post by zilean »

nemothekid wrote: post #21
mikekchar wrote: post #17

Earlier quoted context omitted.

Possibly if you have very few dependencies, and those also have very few dependencies it will work out OK. But in a lot of circumstances, this is a recipe for shooting your foot off. For example, if you are building a server application in Node and the total number of included packages can reach into the thousands. And then if you deploy to your server and for some reason it has to update NPM, suddenly you have a pot…

If you define your config to be: some-library>=1.0.0, and your application breaks - then some-library's developer isn't following SemVer anyways, and you are in dependency hell. If some-library's developer doesn't care about compatibility, then it doesn't matter what versioning scheme you use as you will have to whip up that secret sauce anyways. However, that your issue isn't a problem with SemVer, but a problem wit…

> If some-library's developer doesn't care about compatibility, then it doesn't matter what versioning scheme you use as you will have to whip up that secret sauce anyways.

It does. Semver implies semantics arbitrary versioning is not.

Re: Is Semantic Versioning an Anti-Pattern?

#180

Post by eeZah7Ux »

nine_k wrote: post #67
paulddraper wrote: post #64

Earlier quoted context omitted.

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

> Do you ever update software on your computer?

Let's just say it: a lot of web development is done by producing a blob of code and frameworks of the week, getting paid, and not caring about security and maintainability.

The poor practices and tooling are a consequence of this mindset.

Post reply on HN