simplify date component of versioning scheme

[dustymabe]

Up until this point our versioning has looked something like:

• 418.94.202409090849-0

We are moving to a RHEL based base layer and the versioning will look something like:

• 9.4.202409090849-0

As part of this I propose that we simplify the date component of the version to just daily precision. I argue that the hour/minute in the component make that part of the version too hard to read for humans such that they often ignore it (I certainly do).

The proposal here is to move to something like this for multiple successive builds on a single day:

• 9.4.20240909-0
• 9.4.20240909-1
• 9.4.20240909-2

This is much easier to parse for humans and makes it clear when it was produced. I think of it like your computer having hardware assisted features for decoding things (like compression or multimedia codecs). It's much easier for the computer to do those things if they have the hardware to help. We as humans easily parse 20240909, but not so much 202409090849.

[jlebon]

From what I remember, the date used to be shorter. It was made longer to make it more unique when the different arches were built by separate Jenkins instances (don't quite recall why, I think it was related to clobbering? git likely has the answer).

This would be trivial to change, but I'm quite sure there are things out there parsing the current format. They might not care about the date component of it, but the parser/regex might currently be accounting for them.

Definitely need to raise awareness on this before changing it.

[dustymabe]

Definitely need to raise awareness on this before changing it.

Agree. Where's the best place to go? Mailing list? openshift/enhancements?

[jlebon]

Probably not worth a full-blown enhancement. aos-devel to start sounds good. And maybe linking to the thread in the ART and DPTP channels.