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

51–60 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#51

Post by vacri »

mikekchar wrote: post #17
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…

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…

That's a problem with Node, not with semver.

Nodejs is the first time I've encountered a deployment problem whose resolution was "you have to upgrade your package manager to a beta version".

Re: Is Semantic Versioning an Anti-Pattern?

#52

Post by kaspm »

ryan_lane wrote: post #48
kaspm wrote: post #42

Earlier quoted context omitted.

to defend the author here, I think they were very clear that semver may not make sense for a very specific type of CD, always-on application. The article supports the thesis as stated in text, but the title is too broad.

semver conveys information about a released product. If you're running an internal project that isn't being released to the outside world and that project isn't a library being used by other services in your environment, then you can number the project any way you want. In fact, you don't even need to number it (you can just use the git SHAs, for instance). semver is useful even if you're releasing something that isn…

That's a fair counterpoint to the article but your example above only demonstrates the library case. You should provide an example that demonstrates the value of semver in a CD, always-on top-level application to give information about schema, cache and configuration incompatibilities.

Re: Is Semantic Versioning an Anti-Pattern?

#53

Post by flukus »

kibwen wrote: post #26
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…

IME this problem is particular to NPM, due to JavaScript's historically-anemic standard library which made a culture of microlibraries inevitable. The lesson is that programming languages should provide rich operations on their standard types so that users can avoid having to transitively depend on ten different versions of left-pad.

The problem might be particularly bad in NPM but it is not unique too it.

Re: Is Semantic Versioning an Anti-Pattern?

#54

Post by taeric »

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 will update when they have to. And it is rarely easy, then.

Re: Is Semantic Versioning an Anti-Pattern?

#55

Post by chetanahuja »

mikekchar wrote: post #17
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…

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 are building a server application in Node and the total number of included packages can reach into the thousands"

You know, this should be a hint that the problem is perhaps not with the versioning system.

Re: Is Semantic Versioning an Anti-Pattern?

#56

Post by flukus »

dpark wrote: post #37
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 deploy unknown and untested packages to production, semver is not your problem. The utter lack of testing is. When you actually push to production, your packages should be locked to what you tested. This doesn't prevent the use of version ranges during development or testing. Edit: To be clear, I do not work with Node. If this is standard practice for Node shops, that's terrible.

This often results in security patches not being pushed. IME most companies are awful when it comes to maintaining dependencies, things are all to often locked until someone adds a package.

Re: Is Semantic Versioning an Anti-Pattern?

#57

Post by flukus »

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…

I agree, SemVersion is a technical solution for what is often a human/corporate problem.

A good solution to this is to have an "edge" build that will upgrade dependencies and let you know about breakages early, but that still requires companies to acknowledge that all software needs maintaining.

Re: Is Semantic Versioning an Anti-Pattern?

#58

Post by eridius »

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.

Re: Is Semantic Versioning an Anti-Pattern?

#59

Post by Groxx »

kaspm wrote: post #52
ryan_lane wrote: post #48

Earlier quoted context omitted.

semver conveys information about a released product. If you're running an internal project that isn't being released to the outside world and that project isn't a library being used by other services in your environment, then you can number the project any way you want. In fact, you don't even need to number it (you can just use the git SHAs, for instance). semver is useful even if you're releasing something that isn…

That's a fair counterpoint to the article but your example above only demonstrates the library case. You should provide an example that demonstrates the value of semver in a CD, always-on top-level application to give information about schema, cache and configuration incompatibilities.

To use the web-service example: if you present an API for others to call, even if you never version yourself, you probably still version your API. Other posts on that blog mention doing so.[1]

Well, if you release a ton of versions of your API, some of them are going to be easier to transition between than others. As soon as that occurs, you conceptually have at least major and minor versions, but in a url-based API instead of in code. Or you choose to not hint your consumers if moving from v23 to v24 is likely to be simple or not.

[1]: https://surfingthe.cloud/ideal-api-versioning/ is mentioned in the article, for example.

Re: Is Semantic Versioning an Anti-Pattern?

#60

Post by kaspm »

Groxx wrote: post #49
kaspm wrote: post #42

Earlier quoted context omitted.

to defend the author here, I think they were very clear that semver may not make sense for a very specific type of CD, always-on application. The article supports the thesis as stated in text, but the title is too broad.

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 date), this is useful for all sorts of internal tracking questions like: was this feature I requested live by 4/1/2016.

I personally dislike using semvar for these instances (my own opinion only) because it feels overcomplicated as you stated. I also learned a long time ago that _any_ kind of date designator was a recipe for answering why the "April" release was actually live on June 1st ;). Recently, I've dropped back to Git SHA-1 which has alignment to a specific version of code released AND can be tracked by date and deploy tools.

So I agree with the thesis, disagree with the solution, but still think ryan_lane did not effectively refute it above.

Post reply on HN