I honestly love this idea unironically because its not really 1.0 until the bugs are gone and all desired features are present. If there are ever 2.0 plans, those are actually 1.0 plans and you were further behind than you thought
By definition, SemVer is supposed to have meaning to end users. If you see the third number increase, no worries, it’s just bugfixes.
If you see the second number increase, well, in theory no worries, it’s just cool new features but doesn’t break anything you were doing, whatever you were doing should keep on working as always, and you can explore the new features at your leisure.
The first number changes: beware, something you may be used to can change/go away so it’s not necessarily a slam dunk to update that.
The problem is that many projects just call it SemVer when they just play with arbitrary numbers. I’ll call it “Marketing Versioning”.
you can tell SemVer works because this is the first time i’ve ever seen it explained, but i already understood all of it just from using programs (and reading changelogs)
I just don’t see what the point is of making the version the date. If I care about time then look up the release date metadata associated with the version.
Semver shows breaking changes. That seems more important than time to me, and I’d think for most people. Calver implies to me that people are manually reviewing releases and going “yeah this date is more recent so I think I’ll go with that one” which makes no sense to me. Basically everyone has some automated update system.
What does matter to me is if an update with break anything or includes new features.
I’ve started using CalVer (so a relase in October 2026 would be numbered 26.10). This is just so much better for end-user applications.
What’s the benefits here? Why is the semver even bad to begin with? I’m not sure why I’d care that it’s in the hundreds. It’s a number, right?
Dates - I can just look at the release date if I want that.
The only correct system is 0ver.
I honestly love this idea unironically because its not really 1.0 until the bugs are gone and all desired features are present. If there are ever 2.0 plans, those are actually 1.0 plans and you were further behind than you thought
SemVer simply has no meaning to end users.
By definition, SemVer is supposed to have meaning to end users. If you see the third number increase, no worries, it’s just bugfixes.
If you see the second number increase, well, in theory no worries, it’s just cool new features but doesn’t break anything you were doing, whatever you were doing should keep on working as always, and you can explore the new features at your leisure.
The first number changes: beware, something you may be used to can change/go away so it’s not necessarily a slam dunk to update that.
The problem is that many projects just call it SemVer when they just play with arbitrary numbers. I’ll call it “Marketing Versioning”.
you can tell SemVer works because this is the first time i’ve ever seen it explained, but i already understood all of it just from using programs (and reading changelogs)
You know that puts you so far above average, you’re pretty much an outlier though… right? 😅
I just don’t see what the point is of making the version the date. If I care about time then look up the release date metadata associated with the version.
Semver shows breaking changes. That seems more important than time to me, and I’d think for most people. Calver implies to me that people are manually reviewing releases and going “yeah this date is more recent so I think I’ll go with that one” which makes no sense to me. Basically everyone has some automated update system.
What does matter to me is if an update with break anything or includes new features.
Why not just do 2026.10 then?
Because it’s clearly not 1926 and it likely will not be around in 2126.
Maybe the software will be around in 2126, but I most certainly won’t, not my problem 😂
Whoa, you’re the first Lemmy ghost I’ve met 😉
Oops