4 ms·

For those trying to compare it to SemVer, ChronVer seems to have a different target. It mentions web applications and systems that see releases (with continuous

For those trying to compare it to SemVer, ChronVer seems to have a different target. It mentions web applications and systems that see releases (with continuous delivery or not). SemVer remains good for libraries, or anything where there's a clearly-defined API for consumption, because it clearly establishes a set of rules for what to expect. If you're using version 1.0.0 and upgrade to 1.10.30, with SemVer it would remain perfectly compatible, and no change should be required on your part (that's the ideal; of course developers are free to use whatever versions they want and pretend it's valid SemVer). For applications though, I agree that ChronVer seems far more useful, because there's just no real "compatibility" contract with an application. After all, macOS 2017.09.25 seems far more descriptive than "10.13", which means nothing to anyone.

flukus 7y ago
> For applications though, I agree that ChronVer seems far more useful, because there's just no real "compatibility" contract with an application. It's unfortunately becoming less common but there is still a "compatability contract" between developers and users. With 10.13 -> 10.14 upgrade I would expect no major disruptions as a user, I would expect the UI to be nearly identical and no features to be dropped. With a 10.13 -> 11.1 upgrade I would expect "breaking" changes to my interactions and plan to install the update at a convenient time to deal with this. For a 2017.05 -> 2019.08 upgrade I have no indication of what to expect. For something like continuously delivered web applications I don't think any versioning scheme makes sense to user because they have zero control, it's useless information.
- magicalhippo 7y ago
  This is how we do it at work. Features and major changes go into trunk, which gets released in the new versions. Bug fixes get released in earlier versions and up. We do major.minor version numbers, with even major versions being releases and odd being development versions. We also have an user-selectable way to pick version (major and minor) of our program at launch. So if we "dun goofed" in one version, the user can always just relaunch the previous version which worked. Right before xmas I changed it so that if you didn't enter a first name, it would skip the rest of the name and address fields. This went into a new major version, so users were not that surprised to discover this rather big change in UI flow. However I had missed that in one special case, users were required to enter a postal code. The user that reported this could then just launch the previous major version until I got that issue sorted, getting bug fixes for other issues in the meantime.
ShorsHammer 7y ago
> For applications though Often have thought that crypto libraries should be using ChronVer. Unlikely that an implementation will have breaking changes. Besides that certainly agree with everything else.
azinman2 7y ago
“ After all, macOS 2017.09.25 seems far more descriptive than "10.13", which means nothing to anyone.” I don’t understand this argument. Dates are arbitrary, and are subject to how quickly something is released/iterated on. Was there 2 releases a year? Once every two years? It’s hard to understand between different versions how many major potential changes there are. For something like macOS, the number of fundamental under the hood changes are tremendous, coming from a super large organization. Without semantic versioning, it is difficult to create dependencies or explain compatibility, let alone understand how “old” a version someone might be on —- time itself is subjective, while an incrementing counter is not.
- baq 7y ago
  incrementing a counter is as informative as taking the current date. if you want to embed some information about the software in its version number, you have to define the protocol either way, i.e. what events increment a counter. see also vector clocks.
  - strbean 7y ago
    You should write a spec for vectored versioning and register vecver.org to host it :)
    - baq 7y ago
      bzr may have done it already, disregarding the fact that build version != source version.
Dylan16807 7y ago
> After all, macOS 2017.09.25 seems far more descriptive than "10.13", which means nothing to anyone. And then 2017.09.28.83456, 2017.09.28.83457, and 2017.09.28.83458 all come out at the same time. One is a patch to El Capitan, one is a patch to Sierra, and one is a patch to High Sierra. There's absolutely no way to tell which is which. Go ahead and refer to Catalina as 2019.10 or 19.10 or 1910. But keep the same prefix when patching it.
- NetOpWibby 7y ago
  Wouldn't it be something like this? - 2017.09.28-capitan - 2017.09.28-sierra - 2017.09.28-highsierra These are perfectly valid in the spec.

flukus 7y ago

> For applications though, I agree that ChronVer seems far more useful, because there's just no real "compatibility" contract with an application. It's unfortunately becoming less common but there is still a "compatability contract" between developers and users. With 10.13 -> 10.14 upgrade I would expect no major disruptions as a user, I would expect the UI to be nearly identical and no features to be dropped. With a 10.13 -> 11.1 upgrade I would expect "breaking" changes to my interactions and plan to install the update at a convenient time to deal with this. For a 2017.05 -> 2019.08 upgrade I have no indication of what to expect. For something like continuously delivered web applications I don't think any versioning scheme makes sense to user because they have zero control, it's useless information.

magicalhippo 7y ago
This is how we do it at work. Features and major changes go into trunk, which gets released in the new versions. Bug fixes get released in earlier versions and up. We do major.minor version numbers, with even major versions being releases and odd being development versions. We also have an user-selectable way to pick version (major and minor) of our program at launch. So if we "dun goofed" in one version, the user can always just relaunch the previous version which worked. Right before xmas I changed it so that if you didn't enter a first name, it would skip the rest of the name and address fields. This went into a new major version, so users were not that surprised to discover this rather big change in UI flow. However I had missed that in one special case, users were required to enter a postal code. The user that reported this could then just launch the previous major version until I got that issue sorted, getting bug fixes for other issues in the meantime.

ShorsHammer 7y ago

> For applications though Often have thought that crypto libraries should be using ChronVer. Unlikely that an implementation will have breaking changes. Besides that certainly agree with everything else.

azinman2 7y ago

“ After all, macOS 2017.09.25 seems far more descriptive than "10.13", which means nothing to anyone.” I don’t understand this argument. Dates are arbitrary, and are subject to how quickly something is released/iterated on. Was there 2 releases a year? Once every two years? It’s hard to understand between different versions how many major potential changes there are. For something like macOS, the number of fundamental under the hood changes are tremendous, coming from a super large organization. Without semantic versioning, it is difficult to create dependencies or explain compatibility, let alone understand how “old” a version someone might be on —- time itself is subjective, while an incrementing counter is not.

baq 7y ago
incrementing a counter is as informative as taking the current date. if you want to embed some information about the software in its version number, you have to define the protocol either way, i.e. what events increment a counter. see also vector clocks.
- strbean 7y ago
  You should write a spec for vectored versioning and register vecver.org to host it :)
  - baq 7y ago
    bzr may have done it already, disregarding the fact that build version != source version.

Dylan16807 7y ago

> After all, macOS 2017.09.25 seems far more descriptive than "10.13", which means nothing to anyone. And then 2017.09.28.83456, 2017.09.28.83457, and 2017.09.28.83458 all come out at the same time. One is a patch to El Capitan, one is a patch to Sierra, and one is a patch to High Sierra. There's absolutely no way to tell which is which. Go ahead and refer to Catalina as 2019.10 or 19.10 or 1910. But keep the same prefix when patching it.

NetOpWibby 7y ago
Wouldn't it be something like this? - 2017.09.28-capitan - 2017.09.28-sierra - 2017.09.28-highsierra These are perfectly valid in the spec.