7 ms·
I'm not going to advocate for completely abandoning semver, and I do think that people abuse it or try to use it in places where it might not have been original
by MAGZine 6y ago
I'm not going to advocate for completely abandoning semver, and I do think that people abuse it or try to use it in places where it might not have been originally intended.
That said, personally, my most hated anti-pattern (outside of not properly tagging broken interface versions), is people refusing to tag a 1.0. In theory, this allows folks to continue breaking the interface without calling it a broken interface. In practice, these packages are already widely deployed and NOT tagging a major version completely invalidates the versioning mechanism all together.
The versioning scheme cannot do its job unless if you use all three fields. So release a damn 1.0.0 already! Your software will never be perfect. it's ok.
- Filligree 6y agoHold on? My software isn't version 0.x because it isn't stable. It's version 0.x because there's never been a breaking change necessitating a major version bump.
- freehunter 6y agoThat seems like an unusual interpretation of versioning. Version 0.x signals the product is pre-release and unstable. 1.0 is the first stable release. If you’re saying your software is stable at 0.x, just drop the zero. Otherwise you’re likely giving the wrong impression.
- rurounijones 6y agoSemver 0.x.y is by spec definition unstable & wild-wild west. https://semver.org/spec/v2.0.0.html#spec-item-4 https://semver.org/spec/v2.0.0.html#spec-item-4 "Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable." There is no code change that makes 0.x.y turn into 1.0.0. This is covered in the FAQ https://semver.org/spec/v2.0.0.html#how-do-i-know-when-to-release-100 https://semver.org/spec/v2.0.0.html#how-do-i-know-when-to-re... It is a case of something vaguely along the lines of "0.3.5 has been running in prod for X time, I am now confident, I will now tag that same code as 1.0.0"
- cuddlybacon 6y agoTIL! Thanks! I always assumed that if you were doing Semver right, then you could end up at 0.124.2 or something. Glad to learn that’s not the case.
- MaxBarraclough 6y agoPerhaps I'm missing something obvious, but, why not?
- jml7c5 6y agoExample: semver does not require libfoo 0.4.1 and libfoo 0.4.2 to be compatible in any way. Anything can change between them. It's not until MAJOR >= 1 that the MINOR and PATCH numbers have semantic meaning. Say libfoo 0.4.1's furbinate() function draws a pretty picture. When libfoo 0.4.2 comes out and someone calls furbinate(), they may be surprised to have all their files deleted and their screen covered with filthy Latin poetry, but it is allowed per the semantic versioning spec.
- fingerlocks 6y agoSure, but still doesn’t explain why one can’t end up at 0.142.2 as noted by GP. Something is missing from this discussion, ninja edit?
- DougBTX 6y agoA version 0.142.2 is perfectly possible with Semver, it just implies that the the developer has had a lot of iterations on the idea, but never got to the point that they consider stable. If the software had a stable API at that point, but they were still using a 0.x.y version number, then they wouldn't be using Semver properly, since 0.x.y versions are for unstable initial development releases. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4
- 6y ago
- httpsterio 6y agothis makes no sense. If you're at 0.1 and you rewrite your own code and break it, by your logic it shouldn't be 0.2 but 1.0 then? What semver is meant to symbolise is ä that minor and patches from 1.0 forward will remain stable and up until 2.0 during which breakage is to be expected. This means that whatever your project status was at 1.0 should function the same at the minimum level on all versions beginning with 1. This couldn't possibly work if you start counting breaking changes from 0 because right after your first lines of code it's already breaking. You'd have to bump major versions every day.
- z3t4 6y agoMost companies use sentimental versioning rather then semver.
- k3liutZu 6y ago"sentimental versioning" rings so true!
- deleted 6y ago[deleted]
- PeterStuer 6y agoOr they version by marketing
- Spivak 6y agoSure, but even marketing versions are usually backed by the real version if you look for it.
- leetrout 6y agoLooks at Terraform ( ͡° ͜ʖ ͡°)
- joana035 6y agoOne day people will realize that Terraform is actually a disservice ;-) And that IaaC is about the I rather than the C.
- abathur 6y agoLooks at Hugo
- 6y ago
- dragonwriter 6y ago> In practice, these packages are already widely deployed and NOT tagging a major version completely invalidates the versioning mechanism all together. It implies that all releases are potentially equivalent to semver-major releases, but that doesn't invalidate the mechanism. It means there is no such thing as a safe upgrade, though. (I think it's a mistake that semver doesn't didn't keep patch versions as having the same semantics in pre-1.0 releases as post-1.0, though.)
- Vinnl 6y agoYeah exactly. All <1.0 indicates is "we're not really doing SemVer yet, but intend to do so at some point in the future, probably maybe".
- yencabulator 6y agoOr "our tooling or the ecosystem forced us to use SemVer". Or "the available tooling isn't good enough to make strong promises about API stability, and I'd prefer not to lie to you".
- mumblemumble 6y agoI'm actually OK with people following semver, and also refusing to tag a 1.0, as long as they also refrain from advertising the product as stable and production-ready. You can't have your cake and eat it, too.
- mfer 6y agoIf you refuse to tag a 1.0.0 and follow semver it means any change could be a breaking change. This has an impact on consumers of the software. As a consumer, I quite often value stability.
- ninkendo 6y agoI think the idea is that as a consumer, you shouldn’t use pre-1.0 packages in the first place, since pre-1.0 means “not ready for use”.
- robrtsql 6y agoI think it's great that projects hold off on calling a release "1.0.0"--they're signaling to users that value stability like you that they're not ready for you yet.
- levosmetalo 6y agoIf stability is important to you, just don't use software tagged 0.x.y. It's not like it's going to be more stable if the authors are forced to mark it 1.0.0. At least authors are honest that their goal at the moment of release is not stability but their freedom to break it every release if they see a reason for it.
- mumblemumble 6y agoIt's not really about whether the software is actually more stable, it's the signaling the project gives by choosing to hold their version numbers in semver's semantic no-man's-land where the version numbers aren't expected to give a clear indication of the severity of the change. In particular, what the signal says is, "We aren't yet ready to think about or support the needs of someone who's trying to use this in production." Which, if the project is also then pitching the software as production-ready, is a terrible mixed message. Maintainers really should pick one story and stick with it.
- rmorey 6y ago> people refusing to tag a 1.0 Notable offenders listed here: 0ver.org
- esperent 6y agoI'm guessing that website is satire, but if so, they don't make that very clear.
- voiper1 6y agoThey link to https://calver.org/ https://calver.org/ which is about using the date, at least partly... somewhat similar to samver. (Not 100% sure it isn't sarcasm, too.)
- cutemonster 6y agoOffenders? But they say 0.x it's good, in the same ways as zero indexing arrays
- giancarlostoro 6y agoI am also okay with following semver but being allowed to release major versions that dont necessarily warrant "breaking changes." Software has milestones. Lets make them obvious. If from 0.0.1 to 0.7.4 you had like 5 major changes but nothing was broken API wise those should of been 5 major releases...
- blaisio 6y agoStrong disagree. Incrementing the major version in cases like that is just going to confuse people.
- giancarlostoro 6y agoOnly people familiar with semver maybe, but the rest of the world lives on just fine. This is also what release notes are for, to clarify why the major version update. Every project has its own standards, semver is not a law just a sane suggestion.
- rurounijones 6y ago> I am also okay with following semver but being allowed to release major versions that dont necessarily warrant "breaking changes." Then, to be blunt, you are not following SemVer > Software has milestones. Lets make them obvious. SemVer is about signalling to clients what expectations they should have by being able to look at your version number changes. If you don't follow it then you are confusing your clients. > If from 0.0.1 to 0.7.4 you had like 5 major changes but nothing was broken API wise those should of been 5 major releases... Anything <1.0.0 is already, by definition, subject to any change so your example is a bit off. However SemVer, in my opinion, is primarily used for libraries that are part of systems of dependency resolution. If you have a desktop app used by end-users then I wouldn't recommend using SemVer, just do what marketing requires.
- hombre_fatal 6y agoRefusing to tag a v1.0 at least signals your intentions of API instability, so I don't see how it's abuse. Semver without incrementing a 0 major version is just the status quo of arbitrary versioning where anything can break, and you have to scour patch notes to find out. But it's not abuse. It's what we live with with the vast majority of software. The difference is that someone doing that on semver at least may cross the threshold into sanity one day, or is signalling that it's possibly in their roadmap. Seems like a notch better than the rest of software. But I think your frustration makes more sense reserved for the 99% rest of software.
- kerkeslager 6y ago> In practice, these packages are already widely deployed Other people's poor decisions do not confer any obligation on the person doing the versioning.