FCoS versions are not semvers, unable to leverage them inside of more structured systems

[smarterclayton]

The current version numbers of the FCoS image aren't semver, and that blocks a number of tooling improvements we'd like to make in OKD/OCP to leverage the versions the same way we do for Kubernetes to show changelogs and deltas between FCoS versions.

Is there a strong reason to have the current version format? Would there be significant opposition to changing to be reported in semver?

For instance: the current numbering 31.DATE.dev.0 could very easily become 31.DATE.0-dev (which would satisfy both semver meaning and be very understandable), and for stable releases could also match that format while dropping -dev.

The OKD change viewer (https://origin-release.svc.ci.openshift.org/releasestream/4.4.0-0.okd/release/4.4.0-0.okd-2019-12-17-173903?from=4.4.0-0.okd-2019-12-15-221741) now shows when the component version changes:

* Fedora CoreOS upgraded from 31.20191213.0 to 31.20191217.0

and we would like to go further to display details links (to the build details page) and to a diff viewer. Semver is required for us due to some history, so right now I'm doing a transform in order to get those numbers from the upstream versions. It would be great if we could avoid the need to fake that and just point directly to the numbers. RHCoS is planning to go to semver as well for the same reason.

[smarterclayton]

@cgwalters @miabbott

[miabbott]

I wasn't involved with the version number discussion, but the design is laid out here - https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#version-numbers

cc: @jlebon @dustymabe @bgilbert @lucab who were much more involved and know the history

[cgwalters]

No objections from me to tweaking the version number format.

(I feel it's a bit odd to be semver formatted but not actually semver, but OTOH, we might as well avoid being a totally freeform string)

[jlebon]

We originally discussed version numbering in #81 and #211, and although it doesn't look like the tickets captured it, I remember discussing semver insofar as being in agreement that it didn't make much sense for OS versioning (and in fact, part of the point of what we want FCOS to be is that it automatically moves from e.g. 30.x to 31.x without breaking anything).

That said, that's an argument for not constraining ourselves to semver, not an argument for using the semver format anyway. The point that there's software out there that already knows how to parse semver is a good one, and I don't have any issues offhand with switching over.

[jlebon]

coreos/fedora-coreos-releng-automation#67

[dustymabe]

coreos/fedora-coreos-releng-automation#67

let's hold off on any knee jerk changes until we've discussed with the same group that came up with the original versioning

[jlebon]

let's hold off on any knee jerk changes until we've discussed with the same group that came up with the original versioning

Yup, I've clearly marked that PR with the hold label.

[jlebon]

One thing that's not clear and which gets to the heart of this... OKD is rebuilding FCOS today, right? 31.20191213.0 and 31.20191217.0 aren't any versions we've ever released. Is the impetus for this ticket then that OKD has plans to start consuming FCOS content directly? Otherwise, you could pretty easily just override the version at cosa build time.

Note the .dev bit is so that it's clear what builds came from developer systems, and what builds are official. This is why it's the default in the tree; a cosa init ... && cosa build locally will get you .dev builds. The production pipeline overrides this.

[cgwalters]

Yes...though I think what will happen more medium term is that OKD derives from FCOS...so one could imagine that there are two version numbers in there (much like how RHCOS' version includes both RHEL and OpenShift), but we could split them out...

[lucab]

I remember discussing semver insofar as being in agreement that it didn't make much sense for OS versioning

The discussion was at openshift/os#259 (comment), as FCOS did not exist at that point yet.
There was general agreement that the OS we are making doesn't fit in the semver rules. I personally still strongly believe that.

That said, that's an argument for not constraining ourselves to semver, not an argument for using the semver format anyway. The point that there's software out there that already knows how to parse semver is a good one, and I don't have any issues offhand with switching over.

The counter-argument is openshift/os#259 (comment).

[jlebon]

We discussed this at length today at the community meeting. It was sliced, diced, minced, chopped many different ways. A few conclusions:

1. It is useful to have a version string which is easily parsable and orderable.
2. While semver defines both a format and a semantic attached to that format, it's hard to use one without implying the other.
3. Following semver would send the wrong message about our guarantees as an OS, though it's not clear how much confusion this would actually raise among users.
4. Not all software use the semver format. So software which wants to parse version formats from many different sources should instead use generic version parsers. E.g. Fedora/RHEL packages are not mandated to use semver strings (or mandate upstreams to follow semver, and in fact many do not) and tooling for version ordering, changelogs, etc... have been built on top of them.

Questions came up re. what the exact constraints of the system are in the OKD use case, and whether it can either use a more generic version parser or learn to special-case the FCOS versioning scheme.

[smarterclayton]

The OpenShift core component versioning is now out in the wild and under API evolution rules (so we have to be forward compatible for ever).

I guess the next alternative is we coerce fcos into a semver compliant format, and all downstream tools that want to integrate with a viewer can implement a decoerce.

I’ll note OKD not OCP doesn’t use semver strictly on API guarantees because we’ve never found value in it, but we do find value in a clear semantic around version parsing and the rough guidelines for meaning.

I will note picking a completely arbitrary format makes it harder to coerce, so If we do have to coerce it would be helpful for you to document the meaning of each part of your version string and provide some API guarantee that you won’t break your versioning contract over a one to two year timeframe. If you won’t be globally consistent, at least be internally consistent.

Can you provide that doc and guarantee

[bgilbert]

As mentioned upthread, the version scheme is specified here.

Technically we reserve the right to change the scheme at Fedora major bumps. But in practice, numbering changes are disruptive, so I wouldn't expect the version scheme to change for the foreseeable future. And we'll certainly keep the OKD case in mind if considering it.

[bgilbert]

Fedora CoreOS is now GA with the existing version scheme. Per #338 (comment) I'll go ahead and close. Thanks for reporting.