> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1]
What kind of weird reasoning is this? This should be why you use actual semver, and you use the major version to indicate backward compatibility breaking changes, minor versions for new features, and patch versions for bug fixes that don't actually actually change the public API surface.
If you don't want to use semver, just don't use semver.
Sure, depending on how you interpret initial development. FastAPI has 60k stars on GitHub, has been extremely popular for at least four years, and is widely used in production by a lot of people. It's the maintainers' decision what their goals are for a v1 release, but I was personally surprised to learn that it hasn't had one yet. I can see why one might argue that they're not following the spirit of semver at this point.
As long as the developers/maintainers feel like "Anything MAY change at any time" and "The public API SHOULD NOT be considered stable" is true, both the "spirit" and specification (if we may call it so) say it should be on 0.x.z
> If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.
Yeah, doesn't stroke well with "FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly." now does it?
It doesn't matter how quickly you move, you can apply real semver numbering just fine. Five years and a 0 dot one hundred is obeying the letter of the law while being utterly ridiculous.
If that were the case, then the docs would call that out and warn people not to use their project in production. Instead, it's listed in a way that any normal person will read as a point of pride.
This is a good example of people confusing the letter of the law with the spirit of the law.
Semver is not a goal onto itself. Semver expresses a process to help consumers of an interface infer the implications of an upgrade without having any context on what specifics went into a release. Major changes imply breaking changes, minor changes imply addition of backward compatible changes which can prevent future downgrades, and patch releases means a drop-in replacement that fixes bugs.
Each and every single one of these scenarios reflect decisions made by product maintainers on their work's reliability. Semver is the tool, not the cause.
If product maintainers do not care about stable versions, it makes no difference if they comply with semver or not. What number they tack onto a release means nothing. They might as well tag a timestamp.
If they cared about ensuring their consumers that their work is reliable and stable but still reserve the right to break changes, they could blindly do major version releases and even drop any contract testing from their pipelines. They could even go a step further and claim they only support the N last major releases.
Nevertheless, competent maintainers and product managers know beforehand what is supposed to ship with a release, and even plan when and how to ship those changes. If anyone knows beforehand what changes go in a release, they can easily tell beforehand if that release should be major, minor, or patch. This is not rocket science.
> If product maintainers do not care about stable versions, it makes no difference if they comply with semver or not.
Exactly. Here, the maintainer reserves the freedom to break anything at any moment, and correctly uses semver to signal that through version number.
(Not) using semver as a versioning scheme is orthogonal to whether an API is stable.
As a potential user of said package, seeing this (among other things), I choose to use another package (Django REST Framework) whose maintainers do care about not beeaking the API.
You're a few years behind: people actually went "haha, good joke... for real tho that's actually how we version, let's make it official" and then started using it in earnest.
There've been plenty of projects that officially use 0.x versioning for years now.
Yeah, really not though: you clearly haven't seen projects that actually use that as their official versioning policy ever since semver.org got published. So no, the joke didn't go over my head, because zerover stopped being a joke years ago. Unfortunately for everyone, the world took it seriously.
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
That said, I'd argue that this is a little silly. Maybe a better design is to use something I am calling "zero-calver": 0.YYYY.MM.DD. Then use semantic versioning once stability is reached.
This is using semver in the exact way it’s intended but with predictably silly outcomes. For several years now I’ve been of the opinion that this particular aspect of semver is … very bad actually.
For personal projects I skip any zero major prefixes. In their place, I use alpha/beta suffixes and version Major/minor/patch from an initial 1.0 alpha. Hasn’t caused any problems for me.
And to clarify the approach, the equivalent version would be 1.0.0-alpha.100.0. Clear in its meaning, clear in versioning resolution, ambiguous only in its maturity but that’s what the project is trying to do.
Edit: or probably it’s 1.0.0-beta.100.0. That’s still much clearer
Which sucks, to be honest. Just accept that your major can go up to 23.8.3, and it does not make it less professional than 0.231.0. Actually it's better because it said which releases broke backward compatibility and which ones did not.
Using semver doesn't magically make it okay to make breaking changes constantly. It's still a pain for anyone using your library.
Semver explicitly encourages you to use major version 0 during early development for this exact reason, it's up to the maintainers to decide when they can be more stable.
Actually, semver would make sense if people used it correctly.
Changing the major means that it breaks backward compatibility. Changing the minor means that it has new features. Changing the patch means that it had bugfixes.
That's useful for libraries. Of course it's a bit less useful for executables. I just increase the major for executables, but if I need to backport a feature or a fix (to somebody who still uses an older version), then I use the minor/patch.
What kind of weird reasoning is this? This should be why you use actual semver, and you use the major version to indicate backward compatibility breaking changes, minor versions for new features, and patch versions for bug fixes that don't actually actually change the public API surface.
If you don't want to use semver, just don't use semver.
[1] https://fastapi.tiangolo.com/deployment/versions/