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

From the same link:

> How do I know when to release 1.0.0?

> 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.

Or maybe the people using a thing under development that could constantly change in production are 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.

The point is that it shows the maintainers have a severe lack of judgement

> This is semver:

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.

> 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.

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.