5 ms·

> Hotfix releases will have the addition of a suffix. For example, a single hotfix to Dolphin 2409 would be "Dolphin 2409a". Why not stick with the semantic ve

> Hotfix releases will have the addition of a suffix. For example, a single hotfix to Dolphin 2409 would be "Dolphin 2409a". Why not stick with the semantic versioning and simply do: YEAR.MINOR.PATCH?

nfriedly 2y ago
It looks like they're using a third number to signify dev builds (which I think git has built-in support for), so also having a third number signify patches could get confusing. > All subsequent dev builds after a release will be numbers added on to it. For example, 144 commits after 2409 would result in dev build 2409-144. Also, I don't think leading with the year follows semantic versioning either (?)
__s 2y ago
Semantic versioning doesn't really make sense for applications What's a breaking change? Certainly not new year's day
- dagmx 2y ago
  I guess their point is less the support meaning on semver but rather the formatting. 2409a is the same as 24.9.1. But that assumes the 24 prefix is intentional and not accidentally aligning. Imho I’m ambivalent on it. As long as they use an internally consistent versioning scheme, it’s irrelevant how they surface it.
- yjftsjthsd-h 2y ago
  Applications absolutely can have breaking changes; one that's bitten me is alacritty changing its config file format in a way that was neither forward nor backward compatible. There are also data file format changes, but those are at least usually forward compatible (new app can open old files, though old app can't open new files, which still could be a problem). But this tension is also a reason that I've started to endorse adding one more number to get marketing.breaking.feature.bugfix versions, where the latter 3 are semver but the first one is arbitrary. If you're a company, let the marketing dept decide how to set that, and if you're a community project do what you like; using the year as the marketing version is fine.
- whoisthemachine 2y ago
  It can, but you do need to decide which dimension(s) constitute a breaking change. IMO, the UI replaces the API as the main dimension in user facing applications, so if functionality is removed from the UI, or significantly altered, then that constitutes a breaking change.
Technetium 2y ago
YEAR.MINOR.PATCH is not semantic, it's MAJOR.MINOR.PATCH https://semver.org/ https://semver.org/
tym0 2y ago
There is plenty of examples of CalVer https://calver.org/ https://calver.org/

nfriedly 2y ago

It looks like they're using a third number to signify dev builds (which I think git has built-in support for), so also having a third number signify patches could get confusing. > All subsequent dev builds after a release will be numbers added on to it. For example, 144 commits after 2409 would result in dev build 2409-144. Also, I don't think leading with the year follows semantic versioning either (?)

__s 2y ago

Semantic versioning doesn't really make sense for applications What's a breaking change? Certainly not new year's day

dagmx 2y ago
I guess their point is less the support meaning on semver but rather the formatting. 2409a is the same as 24.9.1. But that assumes the 24 prefix is intentional and not accidentally aligning. Imho I’m ambivalent on it. As long as they use an internally consistent versioning scheme, it’s irrelevant how they surface it.
yjftsjthsd-h 2y ago
Applications absolutely can have breaking changes; one that's bitten me is alacritty changing its config file format in a way that was neither forward nor backward compatible. There are also data file format changes, but those are at least usually forward compatible (new app can open old files, though old app can't open new files, which still could be a problem). But this tension is also a reason that I've started to endorse adding one more number to get marketing.breaking.feature.bugfix versions, where the latter 3 are semver but the first one is arbitrary. If you're a company, let the marketing dept decide how to set that, and if you're a community project do what you like; using the year as the marketing version is fine.
whoisthemachine 2y ago
It can, but you do need to decide which dimension(s) constitute a breaking change. IMO, the UI replaces the API as the main dimension in user facing applications, so if functionality is removed from the UI, or significantly altered, then that constitutes a breaking change.

Technetium 2y ago

YEAR.MINOR.PATCH is not semantic, it's MAJOR.MINOR.PATCH https://semver.org/ https://semver.org/

tym0 2y ago

There is plenty of examples of CalVer https://calver.org/ https://calver.org/