Version numbers are meaningless. By that, I mean they convey no useful information. Oh sure, there are conventions: major.minor.patch, even/odd for stable/development versions, and designations like release candidate. But they’re just conventions. Version numbers are chosen by people, so they are subject to all the idiosyncrasies and whims of individuals.
Semantic Versioning, you say? Pshaw. Nobody does semantic versioning. If they did, we’d see dozens of libraries and applications with major-version numbers in the double or triple digits. It’s almost impossible to change software without breaking something. Even a change which is technically a bugfix can easily break a downstream consumer that relied, intentionally or not, on the buggy behavior.
That’s not to say you shouldn’t try to follow semantic versioning. It’s a good idea, and even its author admits that some versioning decisions boil down to Use your best judgment.
The trouble with semantic versioning is that everyone want others to follow it, but no one wants to follow it themselves. Everyone thinks there’s room for one more quick fix, or this change isn’t big enough to warrant a major-version bump, or simply my project is special. It’s a slippery slope from there to redesigning your entire API between versions 2.7.4-RC13 and 2.7.4-RC14.
Everybody does it. I could name names, but that would be redundant. I’m not sitting in a glass house here, either. I caught major flack for breaking the API of a JSON parser – a JSON parser! – between two 0.x releases. People don’t like change, even improvements, if it means the tiniest bit more work for them. Even if the new API is cleaner and more logical, even if you change things that were never explicitly promised by the old API, there will be grumbles and calls for your resignation. It’s enough to make you want to stop releasing things altogether, or to throw up your hands and just number all your releases sequentially, or to go totally off the reservation a have your version numbers converge towards an irrational constant.
Did I mention this was a rant? Please don’t take it too seriously.
Continuing your rant: I also don’t understand why the version number, which is basically a metadata, has to be put in the source code repository.
This just complicate things:
have to “guess” the next version number right after having done a release. And generally change the minor number “just in case” we’re wrong. And have to create a separate commit for this mess
and this does not play well with branches, either
> It’s almost impossible to change software without breaking something.
Sure, if you don’t bother to understand the difference between public and private API.
> basically a metadata, has to be put in the source code repository.
I don’t understand, exactly where would you have it? I mean, it has to be linked to the code somehow.
There’s already the commit SHA1 which uniquely identifies a specific version of the code.
And repo tags to name them in a more understandable form, if one wants.
Or something more radical:
Get rid of version numbers altogether. Just write some tests, which test for the necessary features in your dependencies. A central integration test server will test your software against new releases of your dependencies and tell you immediately any compatibility problems. Should you need a new feature or want a certain bug fixed (or not fixed) just test for it.
Of course the test suite grows to the triple the size of your project just to declare your dependencies. So you extract certain tests into common test suites. But now you start to test the tests…
@Meikel you may not even need to explicitly test for a new feature: just use it. Testing against a known bug, ok. But still “Bug reports” (w/ failing test cases) may be entities of their own bieng “built” by the CI.
In such a system you would be able to query for projects you just broke with your last commit. It would allow to quantitatively assess breakage, to test between two options etc.
I disagree with the statement that the test suite grow to 3x the project size and metatesting – but you already know that :-)