Semantic versioning is for APIs. For an app (mobile, web or desktop), what is an "incompatible change"?
"Subversion" is for any patch (bugfix) release. You have to decide whether a regular release increases masterversion and resets version or just increases version.
Arguably, overhauling/rewriting a major feature or major chunk of UI. Sometimes you intentionally drop features, sometimes you inadvertently do. There's no better way of finding all the bizarre ways users have come up with to use features (or bugs) in ways you never intended.
One of my favorites was a "note" feature, which had fields for Title, Date, User, and half-dozen other things. Literally nothing in our software used any of them, it was just displayed on a screen, and from what we could tell, only a handful of users used the feature and didn't use all the fields. We were rebuilding a major part of the system and the changes meant that the notes UI and database schema had to be reimplemented, so we simplified it to be just a single textarea input.
Turns out we broke an ordering system for one of our major customers -- they were using the Title field for entering order number, and one of the other fields ('Service Requested By' or something like that) for a shipment tracking number, and had a bunch of custom SQL they ran to extract these values, then update the status back from their ordering system.
In this case it was a "major" version bump, so they were doing extra testing and found this problem before upgrading.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Semantic versioning is for APIs. For an app (mobile, web or desktop), what is an "incompatible change"?
"Subversion" is for any patch (bugfix) release. You have to decide whether a regular release increases masterversion and resets version or just increases version.
Apps can have "incompatible changes" also: e.g., if the app safe something on file and change format, or drop support to some hardware.
Arguably, overhauling/rewriting a major feature or major chunk of UI. Sometimes you intentionally drop features, sometimes you inadvertently do. There's no better way of finding all the bizarre ways users have come up with to use features (or bugs) in ways you never intended.
One of my favorites was a "note" feature, which had fields for Title, Date, User, and half-dozen other things. Literally nothing in our software used any of them, it was just displayed on a screen, and from what we could tell, only a handful of users used the feature and didn't use all the fields. We were rebuilding a major part of the system and the changes meant that the notes UI and database schema had to be reimplemented, so we simplified it to be just a single textarea input.
Turns out we broke an ordering system for one of our major customers -- they were using the Title field for entering order number, and one of the other fields ('Service Requested By' or something like that) for a shipment tracking number, and had a bunch of custom SQL they ran to extract these values, then update the status back from their ordering system.
In this case it was a "major" version bump, so they were doing extra testing and found this problem before upgrading.