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”.
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.
SemVer isn’t bad, but it’s kind of pointless in the browsers. The value in SemVer is if you realistically promise to take bumping that first number seriously. Implying you take backwards compatibility seriously, and bugfixes seriously enough to keep patching an ‘old’ version. If you just maniacally bump the ‘backwards incompatible change’ number and never bother to revisit old releases, then I don’t really care about the SemVer.
Of course, I also don’t necessarily care about the CalVer either if there’s update notification in play, the browsers will aggressively let you know you need an update. However if update notification isn’t working or otherwise isn’t in play, then CalVer can at least make you think “24.7… that seems like it might be old, maybe I should look for updates”. In Windows world the CalVer has been informative as the system or corporate IT screw up has frozen a device at 22H2 and trigger some manual effort to figure out/fix whyever the hell the system won’t go to new functional levels.
It depends. If your software lives in a rapidly evolving ecosystem and gets buggier with age, CalVer tells the user how important it is to update. If the ecosystem is stable and you want to inform the user about feature sets and bug fixes, SemVer makes more sense.
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
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.
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”.
In a GUI application every change is a breaking change…
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.
SemVer isn’t bad, but it’s kind of pointless in the browsers. The value in SemVer is if you realistically promise to take bumping that first number seriously. Implying you take backwards compatibility seriously, and bugfixes seriously enough to keep patching an ‘old’ version. If you just maniacally bump the ‘backwards incompatible change’ number and never bother to revisit old releases, then I don’t really care about the SemVer.
Of course, I also don’t necessarily care about the CalVer either if there’s update notification in play, the browsers will aggressively let you know you need an update. However if update notification isn’t working or otherwise isn’t in play, then CalVer can at least make you think “24.7… that seems like it might be old, maybe I should look for updates”. In Windows world the CalVer has been informative as the system or corporate IT screw up has frozen a device at 22H2 and trigger some manual effort to figure out/fix whyever the hell the system won’t go to new functional levels.
It depends. If your software lives in a rapidly evolving ecosystem and gets buggier with age, CalVer tells the user how important it is to update. If the ecosystem is stable and you want to inform the user about feature sets and bug fixes, SemVer makes more sense.
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