Strategy behind version and release process?

[knksmith57]

Hey Team, a few quick questions:

1. What is the reason for versioning nsolid discretely and in a semantically-incompatible way from the node version used in a given nsolid release? Specifically: what value is there in releasing the enterprise version of node v4.4.4 as nsolid v1.3.1?
2. Are nsolid releases versioned using the same semantic bumps as the node version they use? Eg: nsolid v1.2.2 shipped with node v4.3.2, and the next release, nsolid v1.3.0 shipped with node v4.4.3. I assume this is the case, but the "node compatibility" section of the docs don't appear to verify.
3. What is the reason for not-tagging nsolid release images with the corresponding node version used in a given nsolid release? Specifically: provided there is a good reason for q1, what value is there in forcing developers to pin images to nodesource/nsolid:v1.3.1 instead of allowing for something like nodesource/nsolid:node-v4.4.4. It took some googling to arrive at the downloads page, then parse the given release notes for the version of node likely to be running in the published image. For more color, the release notes for v1.3.3 don't state the version of node used (though it seems safe to assume it is v4.4.6, as that version is referenced in the v1.3.2 release notes, which came out the same day).
4. Are there plans to offer minor version tags for safer pinning? Eg: nodesource/nsolid:v1.3 would point to nodesource/nsolid:v1.3.1 right now, as that is the latest patch release for v1.3 on docker. What about offering minor tags for the version of node used? Eg, expanding on q3: nodesource/nsolid:node-v4.4. This can be necessary in the rare situation like the bump from node v4.2.6 to v4.3.0 where a non-backward compatible change was introduced.
5. The docker hub reports the latest available version tag as v1.3.1 (which also matches latest, with hash 5f43b14b140b). When can we expect tags for v1.3.2 and v1.3.3 and what is SLA (if any) for the publishing of these images after an nsolid release is cut?

Thanks for taking the time to check this out :)

[rosskukulinski]

Hi @knksmith57 - good questions and great feedback! @retrohacker manages our Docker releases but he's currently out-of-office for an extended vacation so I'll chime in as best as I can.

1. N|Solid is more than just the runtime (i.e the drop-in replacement for LTS Node). We provide additional features around the node runtime as well as the Console for datacenter-wide visibility into performance of Node processes. We needed a mechanism to describe the addition of new features / bug fixes to our product which may be different from changes to Node Core. It's also important to note that APIs for communication between the NSolid Runtime, Hub, and Console are tied to product release versions, not Node versions. E.g. NSolid Runtime v1.3 should communicate with NSolid Console v1.3.
2. No. NSolid minor/patch bumps are independent from Node.JS minor/patch bumps. Each subsequent release of the N|Solid 1.x series will use the latest Node v4.x LTS version at the time of release. We encourage our users to use the latest 1.x version available to have the most recent Node v4.X LTS version and newest NSolid features. I've got a note to improve the Node Compatibility section of the docs.
3. Our release notes should state the version of Node for each release. You are correct that the v1.3.3 release notes do not include it, and I apologize for that oversight. I discussed this a bit in 1, but primarily this comes down to compatibility between the NSolid components (Runtime, Hub, Console). With that said, however, perhaps our tags could include the Node version (e.g. nodesource/nsolid:v1.3-node_v4.4.6). Would that be helpful?
4. Not at the moment.
5. Ah! Great catch. I'm talking with our engineering team as to when we can ship 1.3.2 and 1.3.3 images. Right now we do not have an SLA for when images will be cut. It's usually done within a day or two but I'm not sure why 1.3.2 and 1.3.3 slipped. Longer-term, we plan on moving Docker support for NSolid as a first-class citizen including shipping Docker images as part of the official NSolid Release. That means same-day releases!

We've been having internal discussions on how to improve the experience of using NSolid in Docker environments. I hope my comments have helped!

[knksmith57]

Hey @rosskukulinski - thanks for following up!

The clarification regarding nsolid versioning is much appreciated and clears up the reasoning for leaving the node version out of the tags. Without offering minor tags and pinning for the node version used in an image, I don't personally see much value in extending tag names to include the bundled node version (eg: nodesource/nsolid:v1.3-node_v4.4.6 doesn't offer any additional control over the minor version of node being shipped, while something like nodesource/nsolid:node_v4.4 could). It does make it much more obvious what version of node you get when pinned to a specific patch release. Maybe it's worth it? Tags are cheap 😉

Regarding the nsoild 1.x tracking node v4.x relationship, just one quick follow-up: in ~3 months, node v6.x will become the next LTS release; I assume that nsolid will major bump at that time and nsolid 2.x will begin to track node v6.x, correct?

If this is the case, I think you should consider publishing, at a minimum, at least one more docker image tag: v1. Currently, developers must either pin directly to a patch release or choose to accept whatever latest points to. Come October, any developer currently using latest (and I suspect most are) might be very surprised to find their applications suddenly running a very different version of the node runtime.

Totally understand if there is a product decision to not publish minor tags, but I think ^^ warrants some discussion.

Thanks again for your time and for following up!

[rosskukulinski]

Sounds like you're all over this @knksmith57 :)

The current plan is to release a major version bump of N|Solid to coincide with the October LTS v6.x.

I agree that a v1 tag makes a lot of sense from a Runtime perspective - I'll need to think through the ramifications for the other N|Solid components and sync up with @retrohacker when he's back.

I'm going to leave this issue open to track ongoing discussion.