[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Checking for rocks up
- From: Dirk Laurie <dirk.laurie@...>
- Date: Wed, 3 Apr 2013 06:49:35 +0200
2013/4/2 Thijs Schreijer <email@example.com>:
> My take (as a SemVer 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.
>  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
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.