Re: Checking for rocks up

[Dirk Laurie <dirk.laurie@...>]

2013/4/2 Thijs Schreijer <thijs@thijsschreijer.nl>:

> My take (as a SemVer[1] advocate) would be to add a flag whether
> the version numbering is SemVer compatible. That would immediately
> take all the ambiguity out of the compatibility question.
...
> [1] http://semver.org

I've read that through once. Here is my list of first impressions.
Any mistake in #2 onwards is caused by #1.

1.  It reads like the small print in a software license, but claims
    to merely nail down what everybody is (sort of) doing already.
2.  It is designed by one of the founders of GitHub.
3.  You number your sofware releases as X.Y.Z, which act like digits
    in a number system with an arbitrarily large basis, not stopping
    at 10. I.e. when X or Y ticks over, the later digits start all over
    from 0.
4.  The whole numbering idea applies only to software that is properly
    documented. Don't release anything otherwise. Keep it on GitHub by
    all means, keep developing it, even tell people abut it, just don't
    issue numbered releases.
5.  You can't re-use the same three numbers if you have changed anything.
6.  You increase X (the major release number) when you have introduced
    a backwards incompatible change, except you don't need to when
    X is still stuck at 0.
7.  You increase Y (the minor release number) when you have added new
    features but all properly documented existing features still work.
8.  You increase Z when you have corrected a bug. Any discrepancy
    between documentation and performance counts as a bug. You can
    correct it either way.
9.  Any software that depends on documented working features of X.Y.Z
    can specify its dependance as `X.Y.Z <= version < (X+1).0.0` and you
    should feel guilty when your new release with the same X breaks
    someone else's application.
10. You should in your documentation deprecate features when it is likely
    that (X+1).0.0 won't support them any more.

I think once these rules are well known and most reputable software authors
follow them, new authors will follow them too. So count this mail as a small
contribution in that direction. (And please correct mistakes in it.)

But if the author of SemVer himself does not specify such a flag, it is not
for us to do so. We can claim SemVer compliance in our documentation.

At present GitHub itself does not impose SemVer on authors, nor does it
offer any mechanism for mapping branches to major releases. In fact does
not even tell authors creating a new repository to go and read the SemVer
specs before issuing any releases.