3 ms·
Semantic versioning makes sense for libraries, not so much for user-facing applications.
by pvdebbe 9y ago
Semantic versioning makes sense for libraries, not so much for user-facing applications.
- lucideer 9y agoI used to agree with the point about year-based versioning, but I've changed my tune and I don't think this point about libraries is completely true either. If you look at what semantic -vs- date-based versioning communicates to end-users of normal user-facing apps: Date-based: - how recently it's been released - not much else The above is useful if you are interested in being up-to-date on a piece of software you know and trust, or in trying out new / cutting edge software. Semantic: - a (very) rough idea of how long it's been in development for (number of versions its gone through) - a (similarly, very) rough idea of how active the development effort is in terms of testing/maintentance/bug-fixes/patches (i.e. major version churn -vs- minor version churn -vs- patch version churn - the likely relative stability of the current release (e.g. 2.0.0 might be less stable than 2.0.4) All of the above may be rough and may give false impressions sometimes, but it is still extremely useful as an indicator for any relatively technical user evaluating whether or not to use or upgrade a piece of software. Less technical users are less likely to be as interested in version numbers full stop.
- vacri 9y agoIf a project actually follows semver, then you know that unless the first number changes, there won't be any (significant) backwards-incompatible changes - eg, your config files will still work as expected.
- pvdebbe 9y agoThis is the major obstacle with semver. People aren't terribly psyched to increase the major version whenever incompatibilities happen, because other people have different expectations of major version numbers.