no.
Is Semantic Versioning an Anti-Pattern?
81–90 of 219 posts
Re: Is Semantic Versioning an Anti-Pattern?
#82I started using semver about two years ago in two of my projects---one a library and another an application. For my library, the versions run (output from "git tag -n"):
6.3.0 Bump version number to 6.3.0.
6.3.1 The "Remake the Makefile" Version
6.3.2 Bug fix---use $(RM) instead of /bin/rm
6.3.3 Bug fix---the "all" target does not depend upon "depend".
6.3.4 Bug fix---add restrict to some parameters.
6.3.5 Bug fix---fix compiler warnings from CLang.
6.3.6 Bug fix---guard against some possibly undefined defines.
6.3.7 Bug fix---update dependencies in Makefile
6.4.0 The "Trees For The Nodes" Version
6.5.0 The "PairListCreate()" Version
6.6.0 The "Go for Gopher URLs" Version
6.6.1 Bug fix---use c99 instead of gcc
6.6.2 Bug fix---use $(DESTDIR) when installing
6.6.3 Bug fix---replace malloc()/memset() pair with calloc()
6.7.0 The "Christmas Cleanup" Version
6.8.0 The "Breaking Up Is Hard To Do" Version
6.8.1 Bug fix---potential buffer overwrite.
6.8.2 Bug fix---add missing headerfile.
For the application, I've found semver not to be much of a win. The versions:
v4.6.0 The 'XXXX FaceGoogleMyTwitterPlusSpaceBook' Version
v4.6.1 Bug fix---double free
v4.6.2 Bug fix---if not using email notification, code doesn't compile
v4.6.3 Bug fix---don't use _IO_cookie_io_functions_t
v4.6.4 Bug fix---potential double free (yet again).
v4.6.5 Bug fix---encoded entries via email mess things up.
v4.6.6 Bug fix---unauthorized person posting via email leads to double fclose()
v4.6.7 Bug fix---a NULL tumbler crashes the program.
v4.7.0 The 'Tumblers Reloaded' Version
v4.7.1 Bug fix---date checking on exiting tumbler_new() was borked.
v4.7.2 Bug fix---previous and last calculations were borked.
v4.7.3 Bug fix---check tumbler date(s) against last entry, not the current time
v4.7.4 Bug fix---current link was wrong
v4.7.5 Bug fix---the assert() when comparing dates was wrong
v4.8.0 The 'Constant Upgrade' Version
v4.9.0 The 'Unused API Paramters' Version
v4.9.1 Bug fix---getline() called with incorrect parameters.
v4.9.2 Bug fix---dependencies got out of whack.
v4.9.3 Bug fix---used the wrong name when generating the tarball.
v4.9.4 Bug fix---removed compiler warnings under different compiler options.
v4.9.5 Bug fix---assert() was too assertive.
v4.9.6 Bug fix---I was a bit too assertive in the callback code.
v4.9.7 Bug fix---fix header guards.
v4.10.0 The 'Spiffier Email' Version
v4.11.0 The 'Go For Gopher' Version
v4.11.1 Bug fix---potential memory leaks fixed
v4.11.2 Bug fix---notify_emaillist() was borked
v4.11.3 Bug fix---memory corruption
v4.12.0 The "Somewhat Arbitrary Christmas Release" Version
v4.13.0 The "Target Advertisers" Version
Re: Is Semantic Versioning an Anti-Pattern?
#83OP should simply use git version hashes for their use case.
Re: Is Semantic Versioning an Anti-Pattern?
#84Earlier 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…
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.
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.
Re: Is Semantic Versioning an Anti-Pattern?
#85This 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…
[deleted]
Re: Is Semantic Versioning an Anti-Pattern?
#86Earlier quoted context omitted.
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.
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.
Re: Is Semantic Versioning an Anti-Pattern?
#87This 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 realized too late for editing it in, but I do want to add that I do not think it is solely pushed by people encouraging this. I honestly think that most proponents of this are incredibly well intentioned.
Which just highlights, to me, that semver is ultimately good intentions masqueraded as a mechanism.
Re: Is Semantic Versioning an Anti-Pattern?
#88Why 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 comp…
You do know that developers are humans, right?
Re: Is Semantic Versioning an Anti-Pattern?
#89Earlier quoted context omitted.
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.
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.
> 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.
Re: Is Semantic Versioning an Anti-Pattern?
#90This 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…
Have you got an example where pure addition breaks the existing compatibility?
> the lie that people will do security and other updates on older versions.
Semver does not say anything will be supported. You still have to know what's going on with your dependencies as far as big releases and patches go. It simply says that is old versions are still supported, they're updates will preserve compatibility.