4 ms·

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

> 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. [1] https://fastapi.tiangolo.com/deployment/versions/ https://fastapi.tiangolo.com/deployment/versions/

deleted 3y ago
[deleted]
foolswisdom 3y ago
FWIW other frameworks (namely, flask) took a similar approach of not moving to 1.0 for a while.
- palata 3y ago
  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.
  - norgie 3y ago
    Seriously, this 0ver nonsense makes it so much harder to deal with upgrading packages. Who cares you bump the major version frequently
the__alchemist 3y ago
FastAPI doesn't use Semver; it uses ZeroVer: https://0ver.org/ https://0ver.org/
- TheRealPomax 3y ago
  No, they don't. They literally link out to semver.org
  - throwawaymaths 3y ago
    Zerover is satire.
    - TheRealPomax 3y ago
      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.
  - _Algernon_ 3y ago
    The joke . . . Your head
    - xctr94 3y ago
      https://www.scienceofpeople.com/sarcasm-why-it-hurts-us/ https://www.scienceofpeople.com/sarcasm-why-it-hurts-us/ Sarcasm isn’t funny to everyone; GP was understandably confused. This isn’t Reddit.
    - TheRealPomax 3y ago
      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. Do try to catch up.
andrewstuart 3y ago
I prefer straight integer version numbers. It's a tendency of developers to make things complex.
- palata 3y ago
  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.
eyelidlessness 3y ago
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.
- eyelidlessness 3y ago
  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
  - TheRealPomax 3y ago
    Not if they've dropped support for several versions of Python over the years, no. More like v5.10.12 This software is absolutely not in alpha anymore, it's used in production and the project even acknowledges this explicitly.
palata 3y ago
Because it seems like devs believe that 1.0.0 means "the API is perfect, it won't break ever again". Somehow they feel like having a version 15.2.3 looks unprofessional (because the API got broken 14 times), but 0.100.0 is perfectly fine. I just don't get it.
- aliasxneo 3y ago
  Just had this conversation the other day. It's become so unusual to see high major versions that it's basically become taboo.
- bombolo 3y ago
  pydantic has done breaking changes 42 times but is on version 2 :) https://docs.pydantic.dev/latest/changelog/ https://docs.pydantic.dev/latest/changelog/
p1necone 3y ago
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.
senko 3y ago
This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ https://semver.org/)
- foob 3y ago
  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.
  - capableweb 3y ago
    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
- brigadier132 3y ago
  The point is that it shows the maintainers have a severe lack of judgement
- TheRealPomax 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - 3y ago
nerdponx 3y ago
Semver specifically allows you to use 0.x for this purpose: https://semver.org/#spec-item-4 https://semver.org/#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. 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.
- palata 3y ago
  Just use semver from the moment it is usable by a third party. Then maybe it goes up to 41.x.x until stability is reached. So what? It's not less professional than keeping 0.x.x forever.

deleted 3y ago

[deleted]

foolswisdom 3y ago

FWIW other frameworks (namely, flask) took a similar approach of not moving to 1.0 for a while.

palata 3y ago
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.
- norgie 3y ago
  Seriously, this 0ver nonsense makes it so much harder to deal with upgrading packages. Who cares you bump the major version frequently

the__alchemist 3y ago

FastAPI doesn't use Semver; it uses ZeroVer: https://0ver.org/ https://0ver.org/

TheRealPomax 3y ago
No, they don't. They literally link out to semver.org
- throwawaymaths 3y ago
  Zerover is satire.
  - TheRealPomax 3y ago
    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.
- _Algernon_ 3y ago
  The joke . . . Your head
  - xctr94 3y ago
    https://www.scienceofpeople.com/sarcasm-why-it-hurts-us/ https://www.scienceofpeople.com/sarcasm-why-it-hurts-us/ Sarcasm isn’t funny to everyone; GP was understandably confused. This isn’t Reddit.
  - TheRealPomax 3y ago
    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. Do try to catch up.

andrewstuart 3y ago

I prefer straight integer version numbers. It's a tendency of developers to make things complex.

palata 3y ago
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.

eyelidlessness 3y ago

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.

eyelidlessness 3y ago
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
- TheRealPomax 3y ago
  Not if they've dropped support for several versions of Python over the years, no. More like v5.10.12 This software is absolutely not in alpha anymore, it's used in production and the project even acknowledges this explicitly.

palata 3y ago

Because it seems like devs believe that 1.0.0 means "the API is perfect, it won't break ever again". Somehow they feel like having a version 15.2.3 looks unprofessional (because the API got broken 14 times), but 0.100.0 is perfectly fine. I just don't get it.

aliasxneo 3y ago
Just had this conversation the other day. It's become so unusual to see high major versions that it's basically become taboo.
bombolo 3y ago
pydantic has done breaking changes 42 times but is on version 2 :) https://docs.pydantic.dev/latest/changelog/ https://docs.pydantic.dev/latest/changelog/

p1necone 3y ago

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.

senko 3y ago

This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ https://semver.org/)

foob 3y ago
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.
- capableweb 3y ago
  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
brigadier132 3y ago
The point is that it shows the maintainers have a severe lack of judgement
TheRealPomax 3y ago
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.
- deleted 3y ago
  [deleted]
- 3y ago

nerdponx 3y ago

Semver specifically allows you to use 0.x for this purpose: https://semver.org/#spec-item-4 https://semver.org/#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. 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.

palata 3y ago
Just use semver from the moment it is usable by a third party. Then maybe it goes up to 41.x.x until stability is reached. So what? It's not less professional than keeping 0.x.x forever.