31–40 of 91 posts
I can’t tell if this is serious or satire. There’s no spec.
It's obviously satirical. If so, the author is brilliant. Otherwise, well... I mean just look at the project show cases. Included are the usual colossal cluster^Wframeworks that power our decaying software infrastructure. Personally, I don't trust anything that either stays perpetually under v1.0 or exceeds v10-15.
What do you think about internet browsers like Firefox and Chromium?
Earlier quoted context omitted.
> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of strictly obeying that until we've reached 1.0 so I went ahead. P…
I understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.
- Serde had made a very slight but breaking change in 1.0, and at that time I think it was impossible to support both Serde 0.9 and 1.0 in a single crate without a hacky workaround (which I only learned much later). So if I had to pick only one version to support, it ought to be 1.0 as the change was trivial to resolve.
- Cargo's use of semantic versioning is, while documented, not strictly conforming because 0.x.y is considered compatible with 0.x.z where x > 0 and y - People complained a lot when Chrono went 0.2.x to 0.3.0 as well. This is IMO the biggest reason to issue a breaking change; if people would complain in either way, I wanted to make a choice that benefits the whole Rust ecosystem more.
If this happen today I would agree that I shouldn't have done that, but I think it was not that clear cut at that time.
In TeX the version approaches Pi, every new version adds a decimal. Elegant, will hold forever!
TeX 3.141592653 is 45 years old. Its companion Metafont has version number 2.71828182, you can see where this is going.
I noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find: - Uvicorn is 0.22 - httpx is 0.24 - starlette is 0.28 And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.
Astonishingly low compared to what? And in what aspects? (Asking unironically.)
Earlier quoted context omitted.
Semantic Versioning requires you to declare a public API, which is not even remotely possible for many projects. If the public API surface is clear semantic versioning does indeed work well, but otherwise it doesn't give much information as users have no idea what the public API would be. Calendar versioning [1] or even a single-number version is more preferred in such situations. [1] https://calver.org/
Yes! Thank you. Exactly this :) Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API. This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases. So I’…
For applications, it goes just like you said.
For APIs on the network, the caller should only get to control the breaking version their request gets routed to (the rest is abstractly owned by the service provider).
I noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find: - Uvicorn is 0.22 - httpx is 0.24 - starlette is 0.28 And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.
Edit to add: If I was an opensource package maintainer again, my first action would be to massively bump the major version number of my packages. HUGE increase in quality right there.
Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
1) major public API change. If you don't have a public API, this should never be anything but 1 and can be hidden from the user. End users don't want these they scare them.
2) minor: any planned release that doesn't break API. End users love these and plan around them.
3) revision: unplanned emergency hotfixes. Naming this way means the "next minor" we were talking about with all stakeholders is still the next minor. It also means our version numbers look like our git dag, since this one would be a branch from the last tag instead of main.
4) release: sometimes something goes wrong during the release itself. The first 3 numbers are public, this is internal-only and only appears in git tags and internal deployment notes. This way every push to prod has a unique version number, but all our change management documents are still accurate even if we had to push 2 or 3 times for a single release.
Why? First digit is about compatibility. All the other digits are about planning.
"We're working towards 1.3"
"we think this feature will be in 1.4".
"We had to release 1.2.1 because of an emergency somebody put Arabic text in their profile picture filename and that brought down the site."
"Turns out that trick with the release pipeline didn't work in prod so we had to make 1.2.1.1 while deploying".
People just love LTS and backwards compatibility too much. I'm one of them. But it slows the industry, when you can't do API refactors and have to keep bad decisions forever. I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. Like new major version every year, deprecate API on the next major version, remove deprecated API o…
When you break compatibility, you force out abandoned crap. I agree you don't want to do it too often; but not doing it at all is (IMHO) worse.
Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
1. version numbers sort numerically and lexicographically in a sensible way, including across projects and packages which use the same format
2. users get educated that these preciously-held ideas they have about software version numbers are complete superstition. Like "something with a zero major number means not production ready", "something with a zero minor number means I should wait until there's a patch", "something with a major number increase means backwards-incompatible", "something with a minor number increase means backwards-compatible"
3. You know when a particular version (of everything) came out. "We started seeing a wierd bug on X date" no longer is impossible to figure out.