The End of Software Versions

by jkarneges • 11 years ago

67 33 11 years ago

ilaksh• 11 years ago

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.

nrh• 11 years ago

  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.

...and pain ensued.

PieterH6• 11 years ago

Citation needed.

If you have an example of problems caused by forwards compatibility, please provide it.

cwyers• 11 years ago

The essay that's quoted from spends the next few paragraphs saying basically that.

kephra• 11 years ago

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.

tpiha2• 11 years ago

Software versioning is not just some bullshit. There are reasons why we use 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.

chmike3• 11 years ago

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.

Gankro• 11 years ago

Isn't this more or less [SemVer](http://semver.org/)? A bit more streamlined from the official SemVer spec, but it's basically a guideline anyway.

PieterH6• 11 years ago

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.

pron2• 11 years ago

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.

chmike3• 11 years ago

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

Thiz• 11 years ago

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.

jghn• 11 years ago

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.

tpiha2• 11 years ago

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.

toothbrush• 11 years ago

...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.

frostmatthew• 11 years ago

The web killed software versioning.

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.

shortsightedsid• 11 years ago

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.

exprx• 11 years ago

It certainly hasn't killed web browser versions yet, and they most definitely matter when it comes to bugs in web apps (or pages).

ExpiredLink• 11 years ago

He probably confuses 'external' versions (APIs, contracts) and 'internal' versions (builds). Both are largely independent of each other.

PieterH6• 11 years ago

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.

aidenn0• 11 years ago

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).

lostcolony• 11 years ago

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.

tacotuesday• 11 years ago

Thank you for summing up that long, dry article in three paragraphs. Upvote for you.

markbnj• 11 years ago

> 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.

jefe_• 11 years ago

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.

egypturnash• 11 years ago

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.

miguelrochefort• 11 years ago

You guys have this all wrong.

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.

crocket• 11 years ago

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 want to see a concrete example.

The End of Software Versions

Related Stories