16 ms·

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>

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,<2.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 likely that I won't accidentally break in some way I didn't expect due to a change upstream. When I want to upgrade to a breaking change release I know I need to go look at the release notes to see what the breaking change is, and then make modifications to my application. If a breaking change is made in a minor or point release I can open a bug with the project so they can revert this change in the next minor or point release. (edited from <=2.0.0 to <2.0.0, as this was my original intent :) )

mikekchar 10y ago
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 potential of any and all of those thousands of packages to break, or interact poorly, or whatever. Since you have specified that anything between 1.0.0 and 2.0.0 is perfectly fine, you have absolutely no idea what secret sauce is necessary to get a working application again. So your website is down for hours while you struggle to figure out a working configuration. /me displays closet full of T-shirts.
- stymaar 10y ago
  > And then if you deploy to your server and for some reason it has to update NPM, suddenly you have a potential of any and all of those thousands of packages to break, or interact poorly, or whatever. Since you have specified that anything between 1.0.0 and 2.0.0 is perfectly fine, you have absolutely no idea what secret sauce is necessary to get a working application again. That's not how you're supposed to use npm. You should never perform an npm update directly in production exactly because of what you describe. The proper way to manage dependencies update in npm is to perform the dependencies' updates in your build process when building your pre-production/staging build and then use the shrinkwrap[1] command of npm to generate a file with all dependencies pinned for production. This way, for a given production deployment, you know exactly what version of which dependencies was being used and you can rollback easily if an update break something. [1] https://docs.npmjs.com/cli/shrinkwrap https://docs.npmjs.com/cli/shrinkwrap
- nemothekid 10y ago
  If you define your config to be: some-library>=1.0.0,<2.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).
  - zilean 10y ago
    > 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.
- apathy 10y ago
  Sounds like an excellent argument for not using node
- zanecodes 10y ago
  > you have absolutely no idea what secret sauce is necessary to get a working application again That's what .lock files are for.
  - ryan_lane 10y ago
    This. You define your loose dependencies, then you compile them down to a lock file that you use to test your service and you deploy with the completely locked down set of dependencies. When you want to upgrade your deps, you re-run the compilation and get updated libraries, which you test again. If you have floating deps in production you're doing it wrong.
- kibwen 10y ago
  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.
  - flukus 10y ago
    The problem might be particularly bad in NPM but it is not unique too it.
    - kibwen 10y ago
      Dependency hell isn't unique to NPM, but it's also not unique to semver. The primary driving feature of semver is that it provides the framework for a social contract between library author and library user about how automatic upgrades can be performed. This works great until you the number of transitive dependencies is "in the the thousands", which I've never seen on any project save for Javascript projects.
- tossedaway334 10y ago
  That speaks more to the insanity of the Node ecosystem than anything else.
- dpark 10y ago
  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.
  - flukus 10y ago
    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.
    - dpark 10y ago
      Which is why I think development should be done without locked packages, locking after testing successfully before the production release. Not taking security patches is bad. Taking down production is also bad.
      - flukus 10y ago
        > Taking down production is also bad I won't say it's ever good, but for most software some downtime isn't the end of the world, certainly better than having security exploits available.
        dpark 10y ago
        I understand that view but I think that the reality is that for many customers, downtime is worse than a potential security breach. Customers would rather downtime than a definite breach, but the chance of a breach is not always as bad as definite downtime. I'm not saying that view is necessarily good, but I think it's common. I also think it's quite common that people assume this is the client view and act accordingly. I definitely think skipping testing with the goal of getting security patches out sooner is a terrible plan except maybe in the case of an active exploit. You can get both frequent patches and high availability.
- ak217 10y ago
  Your problem has nothing to do with semver. The solution to your problem is to use your package manager's dependency freeze utility (npm shrinkwrap in your case), and also to select your dependencies carefully, so you don't end up with thousands of subdependencies (I know some npm packages suffer from dependency incontinence - this is a good reason not to use them).
- vacri 10y ago
  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".
- chetanahuja 10y ago
  "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.
kaspm 10y ago
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.
- ryan_lane 10y ago
  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't a library because it can be used to provide information about backwards incompatibility in things like database schema, cache incompatibilities, configuration file incompatibilities, that'll cause a service to break if updated.
  - kaspm 10y ago
    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.
    - Groxx 10y ago
      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/ https://surfingthe.cloud/ideal-api-versioning/ is mentioned in the article, for example.
- 10y ago
taeric 10y ago
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.
- flukus 10y ago
  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.
  - taeric 10y ago
    The lure of technical solutions is huge. I keep calling for them, at least.
  - azernik 10y ago
    It's more of a technical tool for implementing a certain human/corporate behavior. If your organization is actually following a versioned process, then semver-aware tools are really handy; if you're note, then those tools are at best irrelevant and at worst just get in your way.
- thaumaturgy 10y ago
  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.
paulddraper 10y ago
> Being able to do this is really great: some-library>=1.0.0,<2.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.
- nine_k 10y ago
  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.
  - eeZah7Ux 10y ago
    > 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.
- seagreen 10y ago
  Executables should pin. Libraries should depend on ranges (though they can also pin internally for development).
- AgentME 10y ago
  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.
- 10y ago

mikekchar 10y ago

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 potential of any and all of those thousands of packages to break, or interact poorly, or whatever. Since you have specified that anything between 1.0.0 and 2.0.0 is perfectly fine, you have absolutely no idea what secret sauce is necessary to get a working application again. So your website is down for hours while you struggle to figure out a working configuration. /me displays closet full of T-shirts.

stymaar 10y ago
> And then if you deploy to your server and for some reason it has to update NPM, suddenly you have a potential of any and all of those thousands of packages to break, or interact poorly, or whatever. Since you have specified that anything between 1.0.0 and 2.0.0 is perfectly fine, you have absolutely no idea what secret sauce is necessary to get a working application again. That's not how you're supposed to use npm. You should never perform an npm update directly in production exactly because of what you describe. The proper way to manage dependencies update in npm is to perform the dependencies' updates in your build process when building your pre-production/staging build and then use the shrinkwrap[1] command of npm to generate a file with all dependencies pinned for production. This way, for a given production deployment, you know exactly what version of which dependencies was being used and you can rollback easily if an update break something. [1] https://docs.npmjs.com/cli/shrinkwrap https://docs.npmjs.com/cli/shrinkwrap
nemothekid 10y ago
If you define your config to be: some-library>=1.0.0,<2.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).
- zilean 10y ago
  > 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.
apathy 10y ago
Sounds like an excellent argument for not using node
zanecodes 10y ago
> you have absolutely no idea what secret sauce is necessary to get a working application again That's what .lock files are for.
- ryan_lane 10y ago
  This. You define your loose dependencies, then you compile them down to a lock file that you use to test your service and you deploy with the completely locked down set of dependencies. When you want to upgrade your deps, you re-run the compilation and get updated libraries, which you test again. If you have floating deps in production you're doing it wrong.
kibwen 10y ago
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.
- flukus 10y ago
  The problem might be particularly bad in NPM but it is not unique too it.
  - kibwen 10y ago
    Dependency hell isn't unique to NPM, but it's also not unique to semver. The primary driving feature of semver is that it provides the framework for a social contract between library author and library user about how automatic upgrades can be performed. This works great until you the number of transitive dependencies is "in the the thousands", which I've never seen on any project save for Javascript projects.
tossedaway334 10y ago
That speaks more to the insanity of the Node ecosystem than anything else.
dpark 10y ago
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.
- flukus 10y ago
  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.
  - dpark 10y ago
    Which is why I think development should be done without locked packages, locking after testing successfully before the production release. Not taking security patches is bad. Taking down production is also bad.
    - flukus 10y ago
      > Taking down production is also bad I won't say it's ever good, but for most software some downtime isn't the end of the world, certainly better than having security exploits available.
      - dpark 10y ago
        I understand that view but I think that the reality is that for many customers, downtime is worse than a potential security breach. Customers would rather downtime than a definite breach, but the chance of a breach is not always as bad as definite downtime. I'm not saying that view is necessarily good, but I think it's common. I also think it's quite common that people assume this is the client view and act accordingly. I definitely think skipping testing with the goal of getting security patches out sooner is a terrible plan except maybe in the case of an active exploit. You can get both frequent patches and high availability.
ak217 10y ago
Your problem has nothing to do with semver. The solution to your problem is to use your package manager's dependency freeze utility (npm shrinkwrap in your case), and also to select your dependencies carefully, so you don't end up with thousands of subdependencies (I know some npm packages suffer from dependency incontinence - this is a good reason not to use them).
vacri 10y ago
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".
chetanahuja 10y ago
"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.

kaspm 10y ago

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.

ryan_lane 10y ago
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't a library because it can be used to provide information about backwards incompatibility in things like database schema, cache incompatibilities, configuration file incompatibilities, that'll cause a service to break if updated.
- kaspm 10y ago
  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.
  - Groxx 10y ago
    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/ https://surfingthe.cloud/ideal-api-versioning/ is mentioned in the article, for example.
10y ago

taeric 10y ago

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.

flukus 10y ago
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.
- taeric 10y ago
  The lure of technical solutions is huge. I keep calling for them, at least.
- azernik 10y ago
  It's more of a technical tool for implementing a certain human/corporate behavior. If your organization is actually following a versioned process, then semver-aware tools are really handy; if you're note, then those tools are at best irrelevant and at worst just get in your way.
thaumaturgy 10y ago
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.

paulddraper 10y ago

> Being able to do this is really great: some-library>=1.0.0,<2.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.

nine_k 10y ago
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.
- eeZah7Ux 10y ago
  > 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.
seagreen 10y ago
Executables should pin. Libraries should depend on ranges (though they can also pin internally for development).
AgentME 10y ago
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.
10y ago