Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
What are the horrible things about SemVer? Can you give details?
ZeroVer: 0-Based Versioning
11–20 of 91 posts
Re: ZeroVer: 0-Based Versioning
#12I 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.)
Re: ZeroVer: 0-Based Versioning
#13Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.
What are the horrible things about SemVer? Can you give details?
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.
Re: ZeroVer: 0-Based Versioning
#14I 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.
Are those libraries actually not production ready as might be implied by the 0.x or are they just not willing to bump to 1.x for whatever reason? A lot of the projections mentioned in the submission seem to be production ready despite the version number.
Re: ZeroVer: 0-Based Versioning
#15I 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.)
I use Rust professionally and even though it is a newer language with infinitely fewer developers and sponsoring organizations, the tooling and ecosystem is already superior. `cargo` is superior (in DX terms) to whatever nightmare is current in the Python world, `rust-analyzer` is better than to PyCharm, the ecosystem is smaller but more reliable.
Re: ZeroVer: 0-Based Versioning
#16People 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 on the following major version. So you have 1 year to rewrite your app if necessary.
And supporting old versions for those enterprises who would rather pay than upgrade might be a good source of income.
Re: ZeroVer: 0-Based Versioning
#17I 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.
Are those libraries actually not production ready as might be implied by the 0.x or are they just not willing to bump to 1.x for whatever reason? A lot of the projections mentioned in the submission seem to be production ready despite the version number.
"Production-ready" is a state of mind.
They are widely used in production. Maybe some of them are de-facto production ready. But the developers don't want to make commitments to API stability.
And Python being Python it is very hard to statically enforce that you're upholding SemVer promises.
Re: ZeroVer: 0-Based Versioning
#18I can’t tell if this is serious or satire. There’s no spec.
It should be satire, but it is serious. The spec is SemVer, but only versions starting with a zero are allowed. This just shows that SemVer is bullshit.
It is satire. They want you to do SemVer (or CalVer, etc.) properly. There are arguments against SemVer, but I don't see how this one of them.
Re: ZeroVer: 0-Based Versioning
#19While this is probably satire, I sort of agree with it!
I always thought you just need two numbers, a.b
You increment b when you change something in a backwards compatible way.
You increment a when you make a breaking change.
If you are used to semver, it is like ditching the minor version and calling it a patch.
a.b is if course isomorphic to the 0.a.b system mentioned here.
The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.
Re: ZeroVer: 0-Based Versioning
#20People 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…
> 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. People complained a lot and I had to yank the release in question. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.
[1] https://github.com/chronotope/chrono
[2] https://github.com/chronotope/chrono/issues/146#issuecomment...
[3] https://github.com/chronotope/chrono/issues/156
[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...