Major releases are disasters, and should be avoided whenever possible

If you use semantic versioning in your project — and you should — then you fix bugs in patch releases (e.g. going from v2.4.6 to v2.4.7), and add new features in minor releases (e.g. from v2.4.6 to v2.5.0). These are both unambiguously good things to do: downstream projects that use your project can happily and blindly upgrade to your new versions knowing that everything is compatible and nothing will break.

But when you issue a new major release (e.g. from v2.4.6 to v 3.0.0), that’s because you made an incompatible change. Now the maintainers of downsteam packages have to stop and think and read your release notes before they can be confident whether it’s safe to upgrade, or whether (as with all the various React-related libraries’ major versions) they’re going to have to rewrite their code first. Most often, they won’t have the time or energy to do this for all the many dependencies their project has.

Passing laws and adding BIB-1 diagnostics

Years ago, I was a member of the Z39.50 Implementers’ Group. We’d gather from all around the world, maybe 30 or 40 of us, and meet for several days to discuss and vote on possible extensions to this venerable (and still important) information retrieval standard.

A common item of business was approving a new diagnostic code.

Scottkit is born! Only seven and a half years late!

Those of you who have been reading this blog since 2nd March 2010 — just three days after the blog was born — might remember the fourth post I ever made here: Learning a language vs. learning a culture, on my switching from Perl to Ruby. Way back then, I wrote about “ScottKit — my first non-trivial Ruby program”. Here it is!

React error-message of the day

This just in:

Failed context type: Invalid context `paneset` of type `Paneset` supplied to `Paneset`, expected instance of `Paneset`.

Oh, the joys of front-end development!

(My best guess: I have two slightly different version of stripes-components library that provides the <Paneset> component in my application, and somehow I’ve got hold of one from the wrong instance.)

“What should I prioritise that ahead of?”

My colleague Jason Skomorowski and I (and many others) work together for Index Data on the FOLIO library services platform. There is a ton of work to do — fascinating work at that, so that I often find myself working on it in the evenings, not because of deadline panic but just because it’s fun to do.

Often when a request for a new feature comes in — whether it’s user-visible functionality, or more exhaustive test coverage, or better continuous integration support, or improvements to documentation — Jason often asks this key question:

“What should I prioritise that ahead of?”

Rebooting Linux with every new kernel

Back in the early 1990s, when I was working on Sun’s Unix boxes, it was routine for them to be up for multiple years at a time. A reboot was a big event.

Now here we are in 2017, and every single update to the Linux kernel — of which there are several every week — requests a reboot.

All you need to know about version numbers in one page

A colleague asked me a couple of days ago: “So we roll version numbers forward only with breaking changes, right?”

Well, the best approch for any sane project in 2017 is to follow Semantic Versioning. That is not a long document to read, but here is a summary. In a nutshell, version numbers have three facets, major.minor.patch.

• If your new release breaks something that used to work, increment major.
• If your release adds new functionality that clients might want to rely on, increment minor.
• If your release only fixes a bug, increment patch.

Then dependencies of the form “^3.4.2” (for example, in package.json for a JavaScript project) mean “that version, or anything backwards-compatible with it”. Which means the same major version number (3 in this case) and the same or better minor number (4 or higher); or, if the minor version is the same, then the same or better patch level (2 or higher).

This is an excellent, simple and battle-proven system.

However.

How do people manage JavaScripts projects that contain multiple NPM packages?

With my Index Data colleagues, I am working on “Stripes”, a UI toolkit for the in-progress library services platform FOLIO. Because it runs in the browser, the Stripes code pretty much has to be JavaScript, and because it’s a non-trivial bit of work, it brings in multiple modules from elsewhere — something that is traditionally done using NPM, the Node Package Manager, which is what we too are using.

But Stripes is made up of several NPM packages: stripes-core, stripes-connect, and so on. And they use each other. In particular (let’s make things simple by picking a single example), stripes-core uses stripes-connect.

The worst decision in the design of the Internet

The Internet is a frankly incredible design. The IP protocol, which is at its heart, is technology from 1974. TCP, which implements connections on top of IP’s packet delivery, is from the same year. Forty-two years on, both are essentially unchanged. Even DNS, the domain-name service, dates back to 1983, and is going strong 33 years in with only minor tweaks.

The only big change in this time has been the slooow migration (still in its early stages really) from IPv4 to IPv6 — something that has proven necessary as the Internet has been so wildly more successful and popular than anyone anticipated, and the 32-bit-wide host addresses are running out. But in the scheme of things, this is a minor tweak. We’re running the Internet on 1970s technology, not due to sloth, but because it’s good.

A coding confession

I just found this code in one of my source files:

for (HashMap.Entry<String, Void> e2: map.entrySet()) {
  if (eventName.equals(e2.getKey())) {
    m.handle(eventName, data);
  }
}

Yes. I was iterating through the keys in a HashMap to find out whether the one I wanted was there. But the whole point of a HashMap is that looking up a key is an O(1) operation.

What I should have written is:

if (map.containsKey(eventName)) {
  m.handle(eventName, data);
}

The moral of the story: I can be really, really dumb. (But hey, at least my code worked!)