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

21–30 of 219 posts

Re: Is Semantic Versioning an Anti-Pattern?

#21

Post by nemothekid »

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 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 with NPM/node. SemVer is working as intended, but getting the "secret sauce" to get everything working can be confusing as you try and figure out the differences between "devDependencies" and "peerDependencies". If every module just managed their dependencies, it could be easier (on your development experience, but not on your hard disk and build times).

Re: Is Semantic Versioning an Anti-Pattern?

#22

Post by apathy »

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…

Sounds like an excellent argument for not using node

Re: Is Semantic Versioning an Anti-Pattern?

#23

Post by syrrim »

Semantic versioning works great for software like Java. When you deliver an application with java, you want to ensure that the vast majority of your users have a compatible Java version. You also want to make sure that a new version of Java doesn't break your software. Semver encodes both these properties. Since the first number in Java's semantic version is always one, you know it is always backwards compatible. Whenever the second number increments, you know new features have been added that require a new VM. The last number changing is mostly irrelevant to most people, but it might signify a bug fix or optimization.

When both those pieces of information - backwards compatibility and the need to upgrade - are important, semantic versioning should be used. If you are comfortable removing features without leaving an out for users, and you can reliably upgrade all users at the same time, encoding this information is much less important.

Re: Is Semantic Versioning an Anti-Pattern?

#24

Post by zanecodes »

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…

> you have absolutely no idea what secret sauce is necessary to get a working application again

That's what .lock files are for.

Re: Is Semantic Versioning an Anti-Pattern?

#26

Post by kibwen »

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…

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.

Re: Is Semantic Versioning an Anti-Pattern?

#27

Post by tossedaway334 »

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 speaks more to the insanity of the Node ecosystem than anything else.

Re: Is Semantic Versioning an Anti-Pattern?

#28

Post by apathy »

This is punishingly stupid. If you are working on a large enough project (many libraries, many developers, many organizations, daily or nightly builds because it takes 4 hours to run all the unit tests even in parallel due to dependencies) you use semantic versioning.

If you're some pissant shop writing CRUD apps then yeah, don't bother. As soon as you outgrow that stage, there won't be any more questions.

Monolithic standalone apps or tiny projects don't need semver. Practically all collaborative software in between benefits massively from it.

Post reply on HN