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

21–30 of 91 posts

Re: ZeroVer: 0-Based Versioning

#21

Post by conradludgate »

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

Re: ZeroVer: 0-Based Versioning

#22

Post by r4indeer »

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.

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!) for static analysis, black for code formatting (I really miss an opinionated formatter like this in other languages), etc. They also work just fine. Python tooling doesn't seem bad to me.

[1] https://python-poetry.org/ [2] https://github.com/astral-sh/ruff [3] https://mypy-lang.org/

Re: ZeroVer: 0-Based Versioning

#23

Post by chronogram »

lifthrasiir wrote: post #20
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. 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. P…

I understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.

Re: ZeroVer: 0-Based Versioning

#24

Post by hnlmorg »

lifthrasiir wrote: post #13
pictur wrote: post #11

Earlier quoted context omitted.

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. [1] https://calver.org/

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’ve usually ended up changing the versioning scheme to build number (generated by the CI/CD tooling) plus some extra information like git hash and/or timestamp - depending on the application and whether that build information can be easily encoded as additional metadata or not.

Re: ZeroVer: 0-Based Versioning

#25

Post by zetalyrae »

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!)…

I'll grant it could be much worse (Common Lisp, OCaml also have significant tooling problems). I haven't used mypy but I do use pyright and it's alright.

The only way I've found to make Python tolerable is 1) lots of dataclasses and 2) using it as a more strongly-typed bash (i.e.: not for building large and complex software objects).

Re: ZeroVer: 0-Based Versioning

#26

Post by [deleted] »

netmare wrote: post #3
thatxliner wrote: post #2

I can’t tell if this is serious or satire. There’s no spec.

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.

[deleted]

Re: ZeroVer: 0-Based Versioning

#27

Post by gybon »

I prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world.

Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!

Re: ZeroVer: 0-Based Versioning

#28

Post by b112 »

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…

It takes 3 years minimum, often 5, for non LTS Debian, to cycle through a library revision.

IMO, if you think distros are a thing of the past, or 3 years support of the biggest base distro is slowing things down, you're living in a bubble.

I know you prepended this with a statement saying you love LTS too, but to many, LTS is a decade or more.

And really, I have no interest running 'new shiny'. That is the absolute opposite of stable. That is where horrible, life altering mistakes live. If you want to increase your workload 100x, run bleeding edge.

And bleeding edge is anything that has any code change, outside of bug fixes and security fixes.

I know my position is not popular, but that doesn't make it wrong.

Re: ZeroVer: 0-Based Versioning

#29

Post by pravus »

pictur wrote: post #11
lamontcg wrote: post #5

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?

People take it too seriously and don't realize that you can't realistically categorize every single change neatly into 3 separate breakage categories. Arguments abound about how to manage this properly with all sorts of schemes. The fact that "0" is a special case that deserves any consideration is an example of it being broken, imo. What does it actually matter what the first digit is?

Version numbers just denote a change happened and you want them to roughly resemble some sort of chronological ordering. Everything else is gasoline for flame wars and company policies.

Re: ZeroVer: 0-Based Versioning

#30

Post by dools »

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.

Post reply on HN