Ah yes, an ideal versioning scheme for modern video game projects!
ZeroVer: 0-Based Versioning
51–60 of 91 posts
Re: ZeroVer: 0-Based Versioning
#52Earlier quoted context omitted.
> 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.
*Node.js & Python developers enter the chat*
Re: ZeroVer: 0-Based Versioning
#53While 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
In theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well.
Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.
Re: ZeroVer: 0-Based Versioning
#54Earlier quoted context omitted.
> 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.
Good point. It's even better when a dependency multiple levels down gets a breaking change and the direct one is unmaintained.
Re: ZeroVer: 0-Based Versioning
#55This is a funny lampooning of SemVer. That’s at least how I choose to interpret it.
Re: ZeroVer: 0-Based Versioning
#56Earlier 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.
The 0ver projects follow SemVer.
Re: ZeroVer: 0-Based Versioning
#57best versioning is svn/p4/g4 monotonically increasing changelist/revision number
Re: ZeroVer: 0-Based Versioning
#58People 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.
That's not true. You can simply put any breaking changes into separate namespaces. Now you have limitless backwards compatibility and yet users can selectively upgrade whenever they want the new features.
Maintain a non-trivial node project for a while and you will see why some people like stability.
Re: ZeroVer: 0-Based Versioning
#59Page should be updated, Terraform nowadays is in the 1.x version timeline.
Re: ZeroVer: 0-Based Versioning
#60People 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…
Like software that requires some time to master. I can't recount all the times when i invested much time into doing it properly, only to have it all become useless and invalidated because upstream decided to throw it all away.
With you having an attitude like you do, why should i even bother with reading your documentation? Give it 2 years and it will all be obsolete. Waste of time.
Fuck innovation. I want tools that exist long enough that i can master them.