Elemental versioning

[kkaempf]

We need to decide on a versioning scheme for Elemental.

Currently we have

• the node-image at 5.3, following SLE Micro version
• builder-image at 5.3, because it's based on SLE Micro (but doesn't have to)
• the elemental-operator, at 0.6.0
• operator-image at 0.6.0
• elemental-register at 0.6.0, synced with elemental-operator
• elemental-cli, at 0.0.16
• elemental, at 0.1.0

The node-image version is probably ok. Should we switch to semantic versioning to show patch versions ? (Or even rename to sle-node-image to make its origins clearer ?)

elemental-operator should be bumped to 1.0.0 for release, no ?

Same for elemental-cli ?

Comments ? Suggestions ?

[fgiudici]

A couple of comments!

I would plan versioning on cards completion / features review. In particular, 1.0.0 on the operator only when we are done with what we think is the bare minimum for 1.0.0 (e.g., security review, and maybe few other pending stuff ... haven't checked yet). So, if we go tech preview with small nits I would keep a version < 1.0.0.

elemental-cli looks to me pretty mature and it really deserves a version bump IMO

[davidcassany]

elemental-operator should be bumped to 1.0.0 for release, no ?

Agree, IMHO this applies to rancher/elemental-operator and rancher/elemental repositories.

We are also missing elemental-toolkit in the list.

In relation to #361, there version for node-image follows rancher/elemental tags. In fact the idea from #361 is that all our artifacts are versioned according git repository tags. So that the tags from our git repositories define:

• rancher/elemental -> node-image and ISOs
• rancher/elemental-operator -> operator-image and operator helm chart (rpm are using tag versions but they are not meant to be distributed)
• rancher/elemental-tooklit -> (rpm part of node-image, not meant to be distributed as RPM)
• rancher/elemental-cli -> builder-image tag (rpm part of builder-image and node-image, not meant to be distributed as RPM)

So it is only these four versions we should care about IMHO. Said that I agree with @fgiudici elemental-cli deserves a version bump, however note these are components that its version is not really user facing. So from the perspective of making a public release what is really important to my eyes are the versions from rancher/elemental and rancher/elemental-operator, probably we could start tagging something like 1.0.0-beta in both? alternatively we could do a minor bump now in both and reserve 1.0.0 for the actual release (for 2.7.0 milestone) without any alpha/beta, I'm fine with both.

I would not follow SLE Micro versioning in any case, IMHO this will turn to be confusing and having SLE Micro 5.3 based on SLE 15.4 is already too much for my brain 😅

[kkaempf]

We are also missing elemental-toolkit in the list.

Added

[kkaempf]

I would not follow SLE Micro versioning in any case, IMHO this will turn to be confusing and having SLE Micro 5.3 based on SLE 15.4 is already too much for my brain sweat_smile

Full ack, lol.

But @agracey might have different requirements 🤔

[agracey]

I have no specific requirements on this other than that it doesn't cause issues for support later.

I agree with @davidcassany's assessment and would add that the elemental-operator and elemental versions should have the same major version at each stable release. Then we can bump the minor version of the image as we get updates from SLE Micro.

IMO, what would be helpful is to have a state policy of how we expect semvar to work between different components.

[davidcassany]

would add that the elemental-operator and elemental versions should have the same major version at each stable release.

I like the idea

IMO, what would be helpful is to have a state policy of how we expect semvar to work between different components.

Yes, I also like the idea to establish some criteria on rancher/elemental and rancher/elemental-operator versioning to actually represent their compatibility. Something like path level does not matter in terms of compatibility (we can always upgrade one if it does not affect the other), different major version means no compatibility at all and we should discuss what different or equal minor version means.

[davidcassany]

Ok after the discussion we had last week I think a good criteria to start with could be (applicable for rancher/elemental and rancher/elemental-operator repositories):

• Use semantic versioning
• Align versions of Elemental Teal image and Elemental Operator (at least at MAJOR.MINOR level).
• Start with 1.0.0 for 2.7.0 milestone RC.
• Always bump, at least, MINOR level version on head releases.
• Leave PATCH level bumps for maintenance releases (to ensure we can bump without overlaps on head releases)
• PATCH level does not define any compatibility constraint between elemental-operator and elemantal-teal.

Remains to be defined the compatibility constraints between Elemental Teal and Elemental Operator. I'd say the simplest options is to assume

• MAJOR.MINOR versions must match in all cases for supported scenarios
• Different MINOR is not explicitly supported but likely to be functional, no API changes

Should we assume different upgrade speeds on Elemental Teal vs Elemental Operator? Elemental Operator are upgrades on management clusters, Elemental Teal upgrades are in place node OS upgrades for managed clusters. I'd expect different criteria on applying updates in these to pieces from a sysadmin perspective. I believe we have to be clear on Elemental Teal vs Elemental Operator versions compatibility.

@rancher/elemental @agracey

[kkaempf]

Waiting for a call with @agracey

[kkaempf]

General guideline on versioning

• Elemental is the glue between SLE (Micro for Rancher) and Rancher Manager. Both with separate lifecycles.
• The dependencies on Rancher (operator, cluster provisioning) are stronger that on SLE (kernel)
• Elemental versioning should be independent from both (SLE, Rancher)

We will start with 1.0.0 and follow semantic versioning.

• The major version will increase when we introduce larger (possibly breaking) changes in the operator
• Larger operator updates (kubebuilder!) should be treated as minor version updates (i.e. update from 1.0.x to 1.1.x)
• Updates of underlying SLE should be treated as minor version updates
• Any other updates increase the patch version

We still need a way to track changes of SLE and how to reflect this in the Elemental Teal version 🤔

[kkaempf]

Considered done.