The End of Software Versions
hintjens.com
hintjens.com
This appears to be simply saying that version numbers are misleading; what is important is not what version number is being used, but what contracts that version number corresponds to.
That is, it's more useful to say "This release adheres to standard A, B and C, and no longer supports D", and talk about interoperability that way, than it is to say "Version X requires talking to version (X-1) or later".
To borrow from a comment another made, I don't care what version my browser is, I -do- care if it supports Websockets or not (and what version, and what it sends across the connection, etc). This article is saying to describe your releases, and what changed in them, in those terms. As a client user of your software, I really don't care about what changes you make under the hood, -unless- they break the contracts I am dependent on. Version numbers obscure what changes matter to me, vs what ones don't, and are thus insufficient. They can, however, be helpful shorthand, if you document accordingly.
Indeed, the version number is just an attempt to draw a big circle around a whole set of statements about contractual compliance and give the set a meaningful label. As such they are often wrong, and really don't transmit much in the way of useful information.
I was surprised not to read more in the piece about the role of automated tests as an enforcer of contractual compliance.
Semantic versioning does make sense and (usually) works when your modules are all small, specific, and self-contained.
This is one thing that the web assembly people may be missing. When I suggested they do semantic versioning for web assembly, one of them told me something along the lines of "feature detection". I.E. referring to the situation we have where you write code in JS and just don't know if it will work until runtime when you check if that feature exists.
One of the reasons they have to do that for the web is that there is a single module version packaged in the browser for everything anyone could think of to put in the browser, so a "Browser API" version number could not give any information about compatibility of specific sub-APIs.
In the context of self-contained, decoupled web assembly modules with specific narrowly defined purposes, semantic versioning will be important. If we can't get those types of modules with web assembly in some context then we will be missing something important I believe.
To fix this problem, we introduced the simple rule that new
stable releases of the software must (a) talk to old stable
releases and (b) they must support existing apps, without
changes. We more or less succeeded with that, so ZeroMQ
versions 3.2 and 4.0 work nicely with 2.2 and 2.1, for
example.
If you have an example of problems caused by forwards compatibility, please provide it.
https://en.wikipedia.org/wiki/Software_versioning
In fact, I'm writing an article on why we need to use it more, even with web based hosted software. Continuous integration and deploying every day without any respect for your users, that's not OK and it will never be OK nor decent thing to do.
Update the parts whenever needed without the user even noticing.
As a user, I especially want software versions to know what I'm using.
I hate it how Facebook pretends that some features are bugs (for example - switching from most recent to top stories in my news feed) and I want to be able to report this, but I'm kept in the dark in regards to versions, changelog, basically everything except the UI.
Not all software are webapps (though I agree versioning is much less important, particularly for the end user, in those cases).
For those of us writing enterprise software that gets installed/ran by customers versioning is pretty important:
* Unlike a website not all our customers are using the same version, so when a bug is reported we need to know what version it was encountered.
* Customers need to know if version X of product A is compatible with version Y of product B.
* Gives customers an idea of the magnitude of changes, e.g. bumping the minor version will usually indicate mostly bug fixes, security updates, and small/non-API-breaking features.
* Facilitates easier communication with QA, beta testers, etc than referring (only) to a build.
Webapps/SAAS applications are clearly different because customers don't install anything and therefore version numbering from a customer perspective does not have any meaning. Therefore, any meaning we attach, is for internal internal consumption only.
In even in that case, I would argue that version numbering is important. E.g the point on easier communication is exactly where internal consumption requires version numbering.
I'll agree with the peddling mediocrity part though. AI CC2015 is chock full of new bugs in core parts of the program.
My impression is that the versioning of ICE [http://www.zeroc.com], I mean the protocol, is the most effective one. The authors learned versioning and interoperability problem the hard way as previous implementors of CORBA.
In this model A version is composed of two numbers, the version and the release. When the version is different, code or protocol are incompatible. Code or protocol supporting one version is not required to support other versions. The release number is incremented at each change. When a code or protocol has release x, it MUST support all releases smaller than x as well, but only with same version. This is a very simple and clear rule.
It allows incremental development and evolution of code and protocol, while ensuring interoperability at the same time. This requires a coordinated version numbering and is not compatible with a pure bazaar development.
So the idea is to formalize this in the form of a document that lists the contracts, their version, and how far the software implements them. This can all be tested from the outside.
It's part of a more general vision of making software to implement contracts rather than to provide features.
BTW, this form of versioning is common in the Java world where APIs are standardised in the form of JSRs. An application server implements multiple JSRs, so every application server version lists what particular JSR (spec) versions it implements.
The JSR reference is interesting, I wasn't aware of it. How well does it work, and what are the problems with it? I assume it gets complex in cases.
Here's an example from Jetty: http://www.eclipse.org/jetty/documentation/current/what-jett...
And here's Tomcat: http://tomcat.apache.org/whichversion.html
(Both are very popular web servers)
But I do like snapshot upgrades of Ubuntu because upgrading is a risky process that requires time. Geeks probably prefer the Debian way with a rolling upgrade. If something doesn't work they can fix it.
For users that are not tech savvy and don't want to fill their head with the versions and dependencies of all the packages the Ubuntu upgrade model is much simpler. The OS and all its packages do share one global version number.
I would say the choice depends on the public. Its not all black and white.
Software will soon 'write itself' (figure of speech, no code will actually be 'written'). This means that the software I use to read emails won't be the same as yours. Software will dynamically adapt to its context and user, which will make the idea of software version obsolete.
Until more people realize that building software and UI by hand is archaic at best, software versionning might remain useful for another few years.
I want to see a concrete example.
Manufacturers of products that have to perform to some standard will put serial numbers on their products and then may issue a recall based upon the serial number; presumably something analogous should be issued where we currently use a version number (e.g. a build ID or git revision).