dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` We are now *releasing* OSTree content every two weeks rather than every night ([link](http://www.projectatomic.io/blog/2017/02/matching-fedora-ostree-released-con...)). 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
walters added a new comment to an issue you are following: `` For CAHC we use a [major.year.serial pattern](https://github.com/CentOS/sig-atomic-buildscripts/blob/master/centos-atomic-...). 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.
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: `` 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 :) ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
jberkus added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
sayanchowdhury added a new comment to an issue you are following: `` I second @jberkus, year/month/day is easier to read and interpret quickly. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
jasonbrooks added a new comment to an issue you are following: `` 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` ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: `` 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 ? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
jasonbrooks added a new comment to an issue you are following: `` We should keep the major version number. It'll be useful for when we start "rolling." ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: `` 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? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
walters added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
walters added a new comment to an issue you are following: `` Pungi issue here https://pagure.io/pungi/issue/544 ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
kushal added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: `` The pungi PR that landed this feature is: https://pagure.io/pungi/pull-request/592
We [enabled this for rawhide](https://pagure.io/pungi-fedora/pull-request/234). 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` ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
dustymabe added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/229
The status of the issue: `decide on version scheme and image naming scheme for f26` of project: `atomic-wg` has been updated to: Closed as Fixed by dustymabe.
cloud@lists.stg.fedoraproject.org
-
Colin Walters -
Dusty Mabe
-
Jason Brooks
-
Josh Berkus
-
Kushal Das
-
Sayan Chowdhury