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

61–70 of 91 posts

Re: ZeroVer: 0-Based Versioning

#61

Post by sgarland »

r4indeer wrote: post #22
zetalyrae wrote: post #15

Earlier quoted context omitted.

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.

I regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works. Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it. Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!)…

Poetry works, but unfortunately it depends on Python and so it frequently breaks unless you’re very careful with your Python environment management.

Installed it with your system’s native version? Good luck getting it to spawn a venv in a newer version. Used a Homebrew version? When it updates, Poetry breaks. Using asdf? Everything breaks, somehow.

I recently tried pipx and have hope that this will persist.

Re: ZeroVer: 0-Based Versioning

#62

Post by jowea »

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.

Not the actual quality but I suspect the perception of quality by some people would genuinely be increased by bumping the version numbers. Maybe it would help with adoption.

Re: ZeroVer: 0-Based Versioning

#63

Post by r4indeer »

sgarland wrote: post #61
r4indeer wrote: post #22

Earlier quoted context omitted.

I regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works. Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it. Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!)…

Poetry works, but unfortunately it depends on Python and so it frequently breaks unless you’re very careful with your Python environment management. Installed it with your system’s native version? Good luck getting it to spawn a venv in a newer version. Used a Homebrew version? When it updates, Poetry breaks. Using asdf? Everything breaks, somehow. I recently tried pipx and have hope that this will persist.

True, that's why they recommend installing Poetry either via their installer or using pipx, as you did.

pipx and pip's externally-managed-environment should help mitigate a lot of the broken environment issues. I use them too.

Re: ZeroVer: 0-Based Versioning

#64

Post by r4indeer »

avgcorrection wrote: post #56
r4indeer wrote: post #18

Earlier quoted context omitted.

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.

The 0ver projects follow SemVer.

In a broad sense maybe, but not really. The spec says:

> 4. Major version zero (0.y.z) is for initial development.

I'd argue that most of the projects we are talking about here are long past initial development.

Re: ZeroVer: 0-Based Versioning

#65

Post by pseudalopex »

lifthrasiir wrote: post #42
clhodapp wrote: post #35

Earlier quoted context omitted.

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 encom…

Many languages have explicit access levels. Others have naming conventions. Library authors use them often.

I think more software follows semantic versioning than before it was codified.

Re: ZeroVer: 0-Based Versioning

#66

Post by avgcorrection »

r4indeer wrote: post #64
avgcorrection wrote: post #56

Earlier quoted context omitted.

The 0ver projects follow SemVer.

In a broad sense maybe, but not really. The spec says: > 4. Major version zero (0.y.z) is for initial development. I'd argue that most of the projects we are talking about here are long past initial development.

For sure. The problem though is that the strongest points of SemVer are the “machine-readable”, straightforward rules, in particular the rules about bumping the major version. But (like you note) SemVer also has this soft rules that goes beyond how to do versions and end up really dictating how a project should be done:

1. You should have a 0.x.x period for initial development

2. This is the not-stable part of the project lifecycle

3. After 1.x.x. you should be conservative about bumping the major version (not sure if this is from the specification webpage or if this is just the culture around SemVer though)

Point 3 might be what keeps projects on 0ver.

IMO SemVer itself (the culture around it can’t be controlled so that’s outside the domain of discourse) should have just dictated the machine-readable things. Thus points 1 and 2 are fine, but point 3 really discourages large major version integers. I guess some projects can’t realistically follow that. Not because the developers are bad necessarily but simply because breaking changes are part of the domain, more or less.

It seems that only projects that end up reaching a low major version over, say, a decade, fit into the SemVer culture (meaning that people won’t complain about the versioning practice). Maybe some projects simply feel that they get less pushback if they stay on 0ver instead of going for 1.0.0 and then having to go up to 7.0.0 or beyond.

A specification which only consists of three integers (plus the optional “beta”, “rc” appends) is inherently limited. Which is why it should be very limited in scope. SemVer should have just stuck to dictating the machine-readable part without having any opinions about how large the major version integer gets. (Again, maybe this is the culture around SemVer, not something from SemVer itself.)

EDIT: Less verbosely: SemVer seems to both dictate the breaking change versioning as well as making infrequent major bumps after 0.x.x. I think that is an overreach if you want your specification to be focused and uncontroversial, because in practice people will end up going back and forth about tradeoffs.

See also: https://news.ycombinator.com/item?id=28090144

Re: ZeroVer: 0-Based Versioning

#67

Post by lifthrasiir »

pseudalopex wrote: post #65
lifthrasiir wrote: post #42

Earlier quoted context omitted.

> 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 encom…

Many languages have explicit access levels. Others have naming conventions. Library authors use them often. I think more software follows semantic versioning than before it was codified.

That's exactly my point. To my best knowledge "semantic versioning" refers to Tom Preston-Werner's codified version, which is not valuable for the aforementioned reasons. The general idea behind semantic versioning is of course valuable, but we already had a word for that... it's called versioning.

Re: ZeroVer: 0-Based Versioning

#68

Post by zokier »

lamontcg wrote: post #5

Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.

To me semver makes only sense if critical bug(/security) fixes will get backported to old major version(s). Otherwise downstream consumers do not really have true choices to make based on the info deduced from semver. Basically if as an upstream your intent is not to support old versions then that heavily implies that everyone should update to latest asap regardless of the brekage.

Re: ZeroVer: 0-Based Versioning

#69

Post by tom_ »

seanhunter wrote: post #40
lamontcg wrote: post #5

Somehow we need a less horrible SemVer or a less horrible social contract around SemVer.

Or just use ISO8601-formatted dates as versions and derive huge benefits. 1. version numbers sort numerically and lexicographically in a sensible way, including across projects and packages which use the same format 2. users get educated that these preciously-held ideas they have about software version numbers are complete superstition. Like "something with a zero major number means not production ready", "something…

I've done this for personal projects for years, for exactly the reasons you state - other than user re-education, my projects don't have enough users to make an impact. For GitHub releases, I get the CI script to do ``git log -1 --format=%cd-%h --date=format:%Y%m%d-%H%M%S'' (producing output along the lines of "20230708-150500-1234567") and use that as the suffix. (Add a -prerelease suffix on if it's coming from a non-default branch.) This sorts nicely and saves me 2 minutes if I need to find the commit in the history.

(These are self-contained projects. I suppose semver does make some sense for libraries that you link with.)

Professionally, it's been 99% Perforce for about 15 years, so it's routine to use the submitted changelist number, submitted changelists being numbered in the order they were subsequently committed. Sadly not fixed-width, but at least Explorer sorts them sensibly.

Two difficulties I have had doing this with git:

- there doesn't seem to be a way to get git to enforce UTC, so the dates are in my local time zone (for my projects this is not really an issue, and my timezone is almost UTC anyway)

- the CI system runs separate builds for different targets, and using the git commit timestamp ensures all builds get the same time stamp. But it's then possible to end up with timestamps significantly different from the actual release time, or (worse) out of order. I could probably do something better about this than my current "solution" of doing nothing, but this has only happened a couple of times

Re: ZeroVer: 0-Based Versioning

#70

Post by zajio1am »

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…

Libraries are not really a problem, as you can have multiple major versions alongside, so i can have gtk2, gtk3 and gtk4 alongside, each offering its API for applications that use it, while actively developed code (in library) does not need to handle deprecated API.

Bigger problems are demons with API, where it is usually not possible to run multiple versions alongside (as they would compete on the same resources or data), so one code have to offer multiple API versions internally.

Post reply on HN