71–80 of 91 posts
I prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world. Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!
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…
Hard disagree. API churn is (one of) the real cost of using libraries / external dependencies, so people would just rather reimplement them themselves or copy the library code directly into their project.
Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
Or just use ISO8601-formatted dates as versions and derive huge benefits. 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…
(1) data analysis oriented code (2) code to run experiments (e.g. psych paradigms)
I often find that in such code, forking is rather more common. That is, the code bases become wider rather than deeper. For example, we might run several experiments that have a strong resemblance to each other, but have any number of (experimentally relevant) tweaks. Within each fork, I rename, and restart the semantic versioning.
Maybe it is time to consider INvers, irrational number versioning, as used in eg TeX https://en.m.wikipedia.org/wiki/TeX 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.
Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
To me semver makes only sense if critical bug(/security) fixes will get backported to old major version(s). Otherwise downstream consumers do not really have true choices to make based on the info deduced from semver. Basically if as an upstream your intent is not to support old versions then that heavily implies that everyone should update to latest asap regardless of the brekage.
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.
How on earth do people get from "the version number starts with a zero" to "the quality is astonishingly low"? It blows my mind. 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.
The most obvious and nefarious example is that the most severe and painful kinds of backward incompatibilities are superficially permissible under SemVer: behavior changes. To confuse the issue even more these behavior changes might be to fix a bug and restore the original or intended behavior of a feature! There's no single best way to communicate that to users through a version number: if libfoo v1.4.3 broke a behavior from 1.4.{0,1,2}, should the fix be in v1.4.4 or v1.5 because technically you're creating a backward incompatibility! Does the answer change if the buggy behavior has been around multiple patch releases or multiple minor releases? Does the scale of the behavior difference impact the versioning scheme chosen? Does the approximate number of users impacted impact the versioning scheme chosen? Probably!
ZeroVer is, in my opinion, a hacky but fine solution to this: no guarantees! The developers just want to develop and it's up to the consumers of the project to figure out what release they want to use. ZeroVer is when a project chooses not to try to communicate very much through version numbers. I think that's often better than some strict adherence to SemVer that falls apart under any sort of reasonable scrutiny.
I like how browsers have gone: basically give up on the traditional Major Version Number. A Chrome 2 or Firefox 2 that is a radical redesign would probably be an entirely new product with new branding and versions. So just bump the first number a lot to communicate feature releases to users, and bump the other numbers for basically internal build reasons. The minor, patch, and build numbers are free to be used and abused for a lot of complex purposes incredibly complex and popular projects like browsers (and operating systems) have.
I think a lot of projects, Nomad included, would probably be best represented by BrowserVer. Nomad is deeply committed to incremental improvements and backward compatibility, so any "Nomad 2.0" efforts are more likely to happen under a new project. Frankly Nomad 1.0 was more about marketing than any sort of meaningful feature or compatibility promise: we wanted to communicate Nomad was stable and reliable. Going from 0.x -> 1.x is an easy way to communicate that even if nothing more significant happened from 0.12 -> 1.0 than had happened from any 0.X -> 0.Y.
I prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world. Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!
Earlier quoted context omitted.
> Semver only makes sense for shared libraries, [...] While it does make more sense for them, that it not even clear as it seems. Library authors rarely define the public API because it is very tedious and hard to complete---there are only some sort of fuzzy and implicit "common sense" definitions. Whenever "breaking" changes happen the definition gets stronger (but still incomplete), and over the time it would encom…
Many languages have explicit access levels. Others have naming conventions. Library authors use them often. I think more software follows semantic versioning than before it was codified.
Generations of programmers come up writing web services where the router forms a hard API layer and they don't see the point in public/private/protected any more, because nobody is ever linking against their code so it doesn't matter.