adding stream information in OS release version string #211
Comments
|
I like Proposal 2 |
|
I like proposal 2 as well, though the verbosity is a bit unfortunate. E.g. these version identifiers will probably end up on the download page too where we'll list the latest version by stream already. Maybe something along the lines of @lucab's abbreviations in #81 (comment). E.g. something like:
? Could also just use all numbers, e.g. have the patch number be 3 digits where the first digit is bumped on each promotion:
etc... |
|
I really like the numeric approach. It's brief, there are no abbreviations to be interpreted, and it sorts cleanly. It also has a nice property that Proposal 2 doesn't: it distinguishes routine promotions from bugfixes. With proposal 2, a user on We won't have release builds for Edit: I meant proposal 2 from #81, not the one from this ticket. |
|
sorry your previous comment has me a bit confused @bgilbert - we decided in #81 (comment) on a Are you in favor of adding stream information (proposal 2 from this ticket) or leaving as is without the stream indicator (proposal 1 from this ticket) ? |
|
@dustymabe I'm suggesting a refinement of @jlebon's proposal that the stream be encoded in the Z value:
In the interest of getting this nailed down, I propose that we pursue that approach. Objections? |
Ahh now it makes sense. I don't think I have any problems with this approach. Call it Proposal 3 maybe? |
Sure. There were also questions about versioning of official nightly non-production builds. Updated proposal:
I don't expect that people will remember all the 0xx mappings; the idea is just that there's some structured way to assign versions to non-prod builds. |
|
I think one concern about having a single Actually.. There's another thought. Why don't we just make all non-production streams have 4 numbers and we'll just know automatically. So keeping with your scheme above 01xx, 02xx, etc.. |
|
if we do the 4 numbers we could match the first number for the devel and prod streams of
Which will make it a little easier to correlate without having to look it up. i.e. if 1xx it is part of next*. If 1xxx it's next-devel. |
|
AIUI the non-production official builds are expected to have exactly one build per day: the nightly snapshot. So the The 10xx/20xx scheme breaks the sort order and I'm concerned that it could confuse users. i.e., 200 is a release users should run, but 2000 is a release users should probably never run. We could reverse the scheme (official releases have 4-digit numbers) but that's starting to feel over-engineered to me. |
hmm.. I guess I was under the impression it doesn't take long to build so we might be iterating many times if we were trying to fix a specific problem in a short period of time and our attempts weren't working |
|
I also have a deeply ingrained dislike to anything that assumes a build can happen at most once a day - for a long time Fedora pungi worked that way. It's just wrong - it's always "night" somewhere in the globe. |
|
I do agree that 10 seems like a safe number, but there can be cases where a "run" fails very early on (maybe some infrastructure/networking related issue) but not so early that a version number hasn't been allocated already. So we start the build, it fails after 5 minutes. Tweak. Build. Tweak. Build.. You can hit 10 quickly. |
Aren't those dev builds though? If a nightly fails, I assume we don't get an official one until the next day. If we do need to debug a prod build issue in prod, we can always borrow one of the other Z ranges to do it. |
|
@dustymabe, @jlebon, and I bikeshedded for a while and came up with a compromise proposal that we hope is good enough for now: OS versions will have the form
A is a revision number, which starts at 0 and is incremented whenever a new official build is needed with the same X.Y.Z parameters as an existing build. Developer builds (those not produced by the official pipeline) will continue being versioned The Z codes were chosen to make production versions short and simple, development versions clearly related to production versions, and mechanical versions clearly separated into a distinct group. The use of a separate A parameter allows an unlimited number of daily builds on all branches. Objections? If none, we're planning to move ahead with this approach soon. |
|
And for those of us that like a little more concrete examples:
|
This script implements the versioning scheme as described in: coreos/fedora-coreos-tracker#211 The tricky bit is the Y component: the "snapshot" date of the Fedora content. The algorithm I went with here is to use the git timestamp of the commit that last changed the base manifest lockfile (e.g. `manifest-lock.x86_64.json`). The reasoning is that this lockfile defines the base content from which we build. These lockfiles are updated by bots daily and are promoted as is through e.g. `testing-devel` -> `testing`, so we correctly maintain the X.Y components of the version during releases. OTOH, the overrides lockfile is maintained by humans, and will be what we use to override content if we need to backport/revert packages and respin a release (and thus, the base lockfile remains the same). The next step is to use this in the FCOS pipeline to drive versioning.
|
I started on an implementation of this in coreos/fedora-coreos-releng-automation#50. |
|
PR in #298. |
This script implements the versioning scheme as described in: coreos/fedora-coreos-tracker#211 The next step is to use this in the FCOS pipeline to drive versioning.
This script implements the versioning scheme as described in: coreos/fedora-coreos-tracker#211 The next step is to use this in the FCOS pipeline to drive versioning.
This script implements the versioning scheme as described in: coreos/fedora-coreos-tracker#211 The next step is to use this in the FCOS pipeline to drive versioning.
This script implements the versioning scheme as described in: coreos/fedora-coreos-tracker#211 The next step is to use this in the FCOS pipeline to drive versioning.
In #81 we decided on the following format for OS versioning:
<Fedora release>.<snapshot YYYYMMDD>.<number>. This format fits both Proposal 2 and Proposal 3 from that ticket. Proposal 2 is the ultimate goal but we may implement Proposal 3 in the interim.One outstanding point from that ticket was whether or not we should include something in the OS version number that indicates what stream this commit was built against. Let's discuss whether we should add a stream indicator in the version number here in this ticket.
Proposal 1
No stream indicator. Manually look up where a commit was built or infer this from the branch/ref information in rpm-ostree
Proposal 2
Add a
+stream(I think this goes along with semver)30.20190628.0+stable30.20190628.0+testing30.20190628.0+testing-develPlease add comments/concerns or other proposals below!
The text was updated successfully, but these errors were encountered: