3 ms·
> For applications though, I agree that ChronVer seems far more useful, because there's just no real "compatibility" contract with an application. It's unfortu
by 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 agoThis 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.