I 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.
If 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.
This 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.
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.