#229 decide on version scheme and image naming scheme for f26
Closed: Fixed 2 years ago Opened 2 years ago by dustymabe.

We are now releasing OSTree content every two weeks rather than every night (link). Next we would like to make the image names that get produced reflect in some way the OSTree content that is baked into the image. During recent development @jlebon actually suggested that we use date based versions for Fedora Atomic Host: something like version: 20170130.0, version: 20170130.1, version: 20170215.0, etc...

Let's decide on what we want the versioning scheme to look like and also what the image names "could look like" as a result of this.


For CAHC we use a major.year.serial pattern. The rationale is that:

Major is obviously important, and first. Year.serial is just an arbitrary identifier. We could shrink it to major.yearsuffix.serial, where "yearsuffix" is just "17", under the theory we'll never have a major span across a century. So e.g. 25.17.0, 25.17.1, 25.17.2, 25.17.3 etc.

in that model I don't think adding just the year and/or yearsuffix gives us that much added value in Fedora (because of the short lifespan of a Fedora number release). I think if we have the date we should have a full yr/month/day. That may be a bit much so let's have a discussion about it :)

Metadata Update from @dustymabe:
- Issue tagged with: meeting

2 years ago

I'd prefer year/month/day, simply because it's fairly difficult for users to figure out what serial number they want, but the date is easy.

I second @jberkus, year/month/day is easier to read and interpret quickly.

Would there ever be more than one version per day? I don't see a problem w/ something like 25.17.0, 25.17.1, 25.17.2, 25.17.3

yes. more than once a day is a possibility that is why I added the number to the end: 20170130.0, 20170130.1

So I think we are settling in on year.month.day.serial where serial is the increment for the number of the ostrees that have been built that day. The remaining question is whether or not we add 25 to the front of it.

so the options are 20170130.0 or 25.20170130.0.

Does this sound like an accurate summary of how this discussion is going? do we need the 25 or is that implied because the remote you are talking to is the ostree repo for f25 ?

We should keep the major version number. It'll be useful for when we start "rolling."

ok so let me flesh this out just a little more. Current proposal is something like 25.20170130.0 just for the OSTree version that is part of the ostree repo; i.e. the version you see when you run rpm-ostree status. Now we have to figure out what we want the disk image name and iso names to look like. Here is what we have today:

Fedora-Atomic-25-20170215.1.x86_64.qcow2

Basically Fedora-Atomic-{major-version}-{compose-date}.{respin-number}.{arch}.qcow2. If we start putting the OSTree version in the name of the images what would it look like? Something like this:

Fedora-Atomic-25-20170215.1-OSTree-25.20170130.0.x86_64.qcow2

Starts to get a little long but I do see the need to have both uniquely identifying compose information as well as uniquely identifying OSTree information in the name. This is just a guess at what this could look like. Thoughts?

Another alternative is that we shorten this by just including a shortcommit of the ostree commit id in the image name:

Fedora-Atomic-25-20170215.1.aabbccdd.x86_64.qcow2

The negative is that OSTree version numbers are less meaningful, the benefit is that the image name isn't absurdly long and doesn't have two datestamps in it.

We'd probably also need the underlying ostree/rpm-ostree tools to support specifying shortcommits, otherwise this would pretty much be useless.

I'd vote for images having a simple serial number - in the case where we have to respin the cloud image because we changed the kickstart but not the tree, we'd go from -1 to -2 or so.

i.e.:

Fedora-Atomic-25.20170130.0-1.x86_64.qcow2

That said I think we're going to run into pungi issues here.

(Also, we should fix the image name to be Fedora-AtomicHost)

That said I think we're going to run into pungi issues here.

Yes. This is modeled from the compose id, which takes the form of Fedora-Atomic-25-20170215.1 with the date embedded in there. I think they did this for good reason and probably not something we can change.

The thing is, pungi predates ostree. It was designed for a world where Fedora had 2 things: RPMs and images. We now have an intermediate stage as ostree. I would argue that the OSTree version should supercede pungi's concept of a version for the most part.

Metadata Update from @dustymabe:
- Issue untagged with: meeting

2 years ago

I'd vote for images having a simple serial number - in the case where we have to respin the cloud image because we changed the kickstart but not the tree, we'd go from -1 to -2 or so.
i.e.:
Fedora-Atomic-25.20170130.0-1.x86_64.qcow2

I like this one.

Metadata Update from @dustymabe:
- Issue tagged with: F26, host

2 years ago

The pungi PR that landed this feature is: https://pagure.io/pungi/pull-request/592

We enabled this for rawhide. The result looks like:

[root@localhost ~]# rpm-ostree status
State: idle
Deployments:
‚óŹ fedora-atomic:fedora/rawhide/x86_64/atomic-host
             Version: Rawhide.20170526.n.0 (2017-05-26 12:54:57)
              Commit: 784ba2b1b0e848734455faa5586544dccc26efc52ecda68cfc3bec6db0285e0c

  fedora-atomic:fedora/rawhide/x86_64/atomic-host
             Version: 25.44 (2017-05-22 12:02:15)
              Commit: 39b52552979afde8f26f3518bbddaaddf2859cb7948f4e2561ab611273dea534

For fedora 26 this will look like: 26.20170526.0

We have decided on the naming/version scheme so this ticket is done. We'll just need to get https://pagure.io/atomic-wg/issue/300 implemented and then we'll have this realized. Closing this ticket in favor of that one.

Metadata Update from @dustymabe:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata