Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZeroVer: 0-Based Versioning

0ver.org

Post reply on HN
Print view View original

41–50 of 91 posts

Re: ZeroVer: 0-Based Versioning

#41

Post by foota »

dools wrote: post #30
vbezhenar wrote: post #16

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…

> So you have 1 year to rewrite your app if necessary Multiply this by the thousands of dependencies modern apps have and the only thing you will ever do is rewrites.

Most applications (even large ones) do not have thousands of direct dependencies.

Re: ZeroVer: 0-Based Versioning

#42

Post by lifthrasiir »

clhodapp wrote: post #35
hnlmorg wrote: post #24

Earlier quoted context omitted.

Yes! Thank you. Exactly this :) Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API. This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases. So I’…

In my opinion, Semver only makes sense for shared libraries, not for applications, or OSes, or for APIs exposed on the network. For applications, it goes just like you said. For APIs on the network, the caller should only get to control the breaking version their request gets routed to (the rest is abstractly owned by the service provider).

> 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 encompass every observable aspect, as the Hyrum's Law suggests.

In either case semantic versioning is not tremendously useful because either users have an incomplete expectation of what major, minor and patch versions mean, or they will be notified of every possible change and the version distinction becomes useless. Semantic versioning is still useful because it was a codification of existing practice where the expectation can be good enough to avoid most issues. There is no actual value added by the codification in my opinion.

Re: ZeroVer: 0-Based Versioning

#43

Post by auggierose »

r4indeer wrote: post #18
auggierose wrote: post #4

Earlier quoted context omitted.

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.

There is no proper use of SemVer. That's why people do lip service to it, but stay with the zero.

Re: ZeroVer: 0-Based Versioning

#44

Post by zetalyrae »

seanhunter wrote: post #36
zetalyrae wrote: post #8

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.

[flagged]

Re: ZeroVer: 0-Based Versioning

#45

Post by raincole »

vbezhenar wrote: post #16

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…

> I think library authors should be more relentless and break compatibility every few years.

...isn't it just how most LTSs work? LTS is long-term support, not life-time support.

Re: ZeroVer: 0-Based Versioning

#46

Post by netmare »

joseluis wrote: post #31
netmare wrote: post #3

Earlier quoted context omitted.

It's obviously satirical. If so, the author is brilliant. Otherwise, well... I mean just look at the project show cases. Included are the usual colossal cluster^Wframeworks that power our decaying software infrastructure. Personally, I don't trust anything that either stays perpetually under v1.0 or exceeds v10-15.

> exceeds v10-15 What do you think about internet browsers like Firefox and Chromium?

I find it ridiculous that Chrome, Edge and Firefox are all currently around v115. It's just a marketing term now. I've seen Firefox and Thunderbird major version numbers change for simple bugfixes. A release date would be enough.

Re: ZeroVer: 0-Based Versioning

#48

Post by seanhunter »

jowea wrote: post #14
zetalyrae wrote: post #8

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.

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.

Only you can decide whether something is production-ready for you. The library author doesn't know what you're trying to do so they can't possibly know whether their library is ready to be used in your production. You could be making an experiment that's going to form part of a payload for a rocket, an embedded device that gets surgically-implanted into people, is life-critical and very hard to update or you could be making an online meme generator. Production-ready really does mean completely different things in these cases.

Re: ZeroVer: 0-Based Versioning

#49

Post by seanhunter »

zetalyrae wrote: post #15
nine_k wrote: post #12

Earlier quoted context omitted.

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.

There is a new generation of Python tooling that is very high quality.

`rye` is the equivalent of `cargo`

`ruff` is the equivalent of `clippy`

Both are single-purpose, highly-functional and blazingly fast. Both written in rust actually :)

Re: ZeroVer: 0-Based Versioning

#50

Post by diarrhea »

conradludgate wrote: post #21
quickthrower2 wrote: post #19

While 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-onl…

It depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit

Same, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.
Post reply on HN