[atomic-wg] Issue #229: decide on version scheme and image naming scheme for f26
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. https://pagure.io/atomic-wg/issue/229 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229: decide on version scheme and image naming scheme for f26
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229: decide on version scheme and image naming scheme for f26
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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-host-continuous.json#L4). 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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
[atomic-wg] Issue #229 `decide on version scheme and image naming scheme for f26`
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-content-with-each-2week-atomic-release/)). 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 ___ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
