A lot of the comments so far seem to be missing the point.
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.
>> 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.
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.
The thing is, when you have a massive monolithic API like ZMQ or (the worst) "HTML5", version numbers cannot be useful.
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.
You're right. The essay is out of date. In fact the "don't break stable contracts" rule has made life much simpler. It took a while for that to work through. I've corrected the text. Thanks for pointing it out.
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.
The web killed software versioning. Do we really care what version of HN are we reading? Or what version of Github are we using? Not at all, we just use it. Browsers are moving in that direction as well, same as OSes like Android and iOS.
Update the parts whenever needed without the user even noticing.
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.
There are several other cases that I can think of as well (like embedded systems). However, the main point is whether or not software is delivered to customers or is served to customers.
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.
In my world versions are absolutely necessary. People need to be able to exactly reproduce what they previously did which means they record the version of everything they've used in the process, often to the point of md5 hashes or gut hashes or what have you. This also includes particular docker images for the OS.
Oh yeah? And how do you tell customer support on which version you've experienced bug?
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.
...except when $somewebsite goes from 1.x to 2.0, and you hate the interface. This recently happened to Last.fm — i would give my first-born for the legacy interface.
You can't even just buy Adobe Creative Suite anymore, you must subscribe, and even then it's Adobe CC not a versioned CS3, CS6, or w/e so they can get away with peddling mediocrity for years without the proof of innovation a version-based system requires. Similar deal with Microsoft, I pay them whatever a month for Office 365 because I couldn't figure out how to just buy the office suite. The other day I saw that Office 2016 is out, great, since I'm subscribing that should be pushed to me, right? I spent several minutes attempting to understand when and how I would receive 2016 and then just gave up. Not a very consumer friendly environment, at least for consumers who are trying to be good and pay for their software.
Adobe regularly refers to CC, CC2014, and CC2015. Even things like CC2015.2 to denote a second minor update. And all of their programs still have a traditional version number somewhere in them; the old warhorses like Illustrator and Photoshop are getting close to version 20.
I'll agree with the peddling mediocrity part though. AI CC2015 is chock full of new bugs in core parts of the program.
I had hard a hard Time understanding the fundamental idea. Could some one provide a TL;DR ?
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.
Fundamentally, a software package implements multiple contracts, that is, protocols and APIs. Each contract has versions. It's like your laptop implements USB3.0, Bluetooth 4.1, m-SATA, etc. You care a lot about the versions of the contracts your laptop (or apps) implement. You care less about the version of the laptop itself.
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.
What is the problem you are trying to solve ? It looks like it is zmq specific. If you decompose a library in different sub libraries, each one with its own version, it may seam that you allow each library to evolve independently. But you are really making things more complicate for the library users. You may create a dependency hell : https://en.wikipedia.org/wiki/DLL_Hell
The problem is that even small libraries end up with multiple public contracts that evolve independently. Trying to identify these with a single version number doesn't work. Allowing major version numbers to define interoperability is even worse. We don't see dependency hell in practice.
I understand what you mean, but for this to be manageable for the end user it should be automatized. On Debian or Ubuntu, when you install a package, all the dependencies are defined. apt-get downloads all related packages taking in account the dependencies. This could be generalized to smaller library units.
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.
But I assume some versioning of the implementation is also required, no? After all, your laptop may claim to implement USB3.0 but has a bug which is particular to this laptop version.
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.
So yes, you'll want (a) good tests and (b) patches for e.g. the USB3.0 implementation. (I realize that's not how it works for hardware, so it's an analogy). What you don't want is a new release that may change X things because you hit a bug in one specific contract.
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.
It works OK. It doesn't get too complicated because spec versions are updated only once every couple of years. So far, the standardized specs (JSRs) approach has worked quite well. Every standard (and there are a lot of them[1]) that is ever complete (many don't) usually has at least three implementations, so often there's plenty of choice.
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.
My idea for o3db is currently: I'm using date to calculate version number. But the server side will announce protocol and version. This allows both a continuous release, and experimenting with server protocols.
PieterH, how did the experiment with CZMQ turn out? I read the article. It sounds good. I just checked CZMQ, but I couldn't find any sign of SBOM in CZMQ.
I don't confuse these. This distinction is precisely the point of the article. You can test external APIs and contracts. You can't test internal versions. You can design systems to be 100% testable via their external contracts. A system implements N such contracts. This list is a solid basis for "what is this software" whereas a single internal version number is not.
The question is what happens when you release a product that supports API/contract version 3.2.6 and passes all tests, but then later a bug was found in its implementation of API/contract version 2.3.6 which did not get discovered by testing?
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).
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.