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

81–90 of 91 posts

Re: ZeroVer: 0-Based Versioning

#81

Post by 26fingies »

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…

OTOH you, as a library supplier, may be somewhat hamstrung to improve things you think ought to be improved but consider the productivity hit to your downstream consumers if you constantly break things for them. Stepping back to consider all parties, for even moderately popular projects the balance is obviously tipped in the favor of the consumers.

There are libraries out there (such as FFMpeg iirc) that will do a yearly major version with breaking changes. This is a good approach imo. FFmpeg consumers know what to expect and when to expect it.

Re: ZeroVer: 0-Based Versioning

#82

Post by lamontcg »

Pxtl wrote: post #38
lamontcg wrote: post #5

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

My rules for 4-number semver: 1) major public API change. If you don't have a public API, this should never be anything but 1 and can be hidden from the user. End users don't want these they scare them. 2) minor: any planned release that doesn't break API. End users love these and plan around them. 3) revision: unplanned emergency hotfixes. Naming this way means the "next minor" we were talking about with all stakeho…

That at least fixes the qualitative nonsense between minor and patch updates.

I think there needs to be better project definitions around what constitutes a major change.

Projects need to be able to define things like dropping support for old versions of the underlying language in minor versions. So that the last version of support that some people might get is "3.2" and "3.3" may not install at all for them. That means that technically they are in a state where they need to do work to upgrade and are "broken" in a sense, but the actual public API of the software has not changed between "3.2" and "3.3". Supported O/S distro versions should also be able to be abandoned in minor releases. Toolchain updates can also happen in minor releases. Pulling in major versions of dependencies which are technically breaking for anyone who hits a diamond dependency issue, but which produce no major breaking API changes should be able to happen in minor versions.

That means that the contract isn't "I can pull in minor versions and you can never force me to do work" but more strictly that the public API the software exposes won't update.

There's also the problem with semver pinning that projects do where they put hard floor and ceiling pins on all their dependencies, even though their software may be fine with a 5-year old version of the dep (they've just never tested) and it may work fine with the next major release of the dep without any changes at all. Ideally for that last problem, the compatibility matrix fed into the dependency solver should really be a bit more malleable, so that the engineer can realize that the next version of dependency breaks everything and they can retconn the compatibility of their software to pin to the last working version of that dependency. This breaks the perfect immutability of literally everything about a software release, but allows for not being able to predict the future.

Re: ZeroVer: 0-Based Versioning

#83

Post by lamontcg »

schmichael wrote: post #78

The purpose of versioning is to communicate something to your users. (It's also necessary to increase over time for package managers to work, but that's an easy bar to reach.) SemVer tries to explicitly define exactly what's being communicated: API compatibility. I think that's great, especially for libraries, but it's neither the whole story nor what's most meaningful for most projects. The most obvious and nefariou…

I think there needs to be a much tighter definition of what the API is and not just the entire surface area.

So if a project does a major update of one of its deps, without changing its own API, or deprecates support for an old language version or distro, it should be able to ship those in a minor version.

That means that consumers who aren't keeping up with the times may be cut off in a minor update and have to do work to consume the next update. There needs to be less of an expectation that "it isn't a major update, so I won't have to lift a fucking finger and its your fault if I need to" which is what SemVer has socially turned into.

Re: ZeroVer: 0-Based Versioning

#84

Post by zajio1am »

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…

> You increment b when you change something in a backwards compatible way.

Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users.

For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.

Re: ZeroVer: 0-Based Versioning

#85

Post by zajio1am »

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…

That only works for software with simple linear versioning. If i have two major versions (say 2 and 3), i could still release a minor version to the older major version (so i would release 2.8, then 3.0, then 2.9, then 3.1).

Re: ZeroVer: 0-Based Versioning

#86

Post by pseudalopex »

lifthrasiir wrote: post #67
pseudalopex wrote: post #65

Earlier quoted context omitted.

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.

I thought you were separating semantic versioning practices and the Semantic Versioning codification.

Versioning includes many practices outside semantic versioning obviously. Rational numbers. Odd minor version is unstable. Last number at least 90 is unstable. No patch versions. No minor versions. Incompatible minor versions. Dates.

I rejected your claim library authors rarely define the public API. And Hyrum's law makes semantic versioning imperfect but not useless.

Re: ZeroVer: 0-Based Versioning

#87

Post by pseudalopex »

lamontcg wrote: post #80
pseudalopex wrote: post #65

Earlier quoted context omitted.

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.

Explicit access levels keep on getting eroded. Generations of programmers come up writing web services where the router forms a hard API layer and they don't see the point in public/private/protected any more, because nobody is ever linking against their code so it doesn't matter.

Generations of programmers wrote application code where access levels didn't matter. The concept of public and private API is relevant in web services even when language access levels aren't. And erosion is not evident to me.

Re: ZeroVer: 0-Based Versioning

#88

Post by paulryanrogers »

resonious wrote: post #54
foota wrote: post #41

Earlier quoted context omitted.

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

Good point. It's even better when a dependency multiple levels down gets a breaking change and the direct one is unmaintained.

Who keeps unmaintained, direct dependencies in their projects? Seems like basic hygiene to replace them.

Re: ZeroVer: 0-Based Versioning

#89

Post by kerkeslager »

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…

> But it slows the industry, when you can't do API refactors and have to keep bad decisions forever.

It slows the industry when you're spending all your time rewriting code that already works.

The question is, who is slowed down: API creators or API users? If you make regular breaking changes to APIs, it's API users who get slowed down, if you don't it's API creators who get slowed down.

Given the entire point of things that have APIs (libraries, frameworks, centralized services, etc.) is that there are many users and few creators, it's pretty clear which slows down more people.

Additionally, with good API design, you can often maintain namespaced APIs in tandem with very little additional cost. I've got a /v1/blah API and a /v2/blah API on one of my clients' websites--the v1 directory hasn't been touched in 7 years, because all the bugs anyone cares about have been fixed. It still has users (at least officially, I haven't looked at the reporting to see how often they're actually hitting those APIs). The users simply don't care about the new features in the new API, and it's not our place to force them to care.

You can do similar things with libraries (think sqlite vs. sqlite3) but this is obviously harder with frameworks (which is one of the reasons to not like frameworks). It doesn't work everywhere but it works often.

Re: ZeroVer: 0-Based Versioning

#90

Post by quickthrower2 »

zajio1am wrote: post #84
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…

> You increment b when you change something in a backwards compatible way. Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users. For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible devel…

I think you have changed my mind, thanks!
Post reply on HN