jlebon added a new comment to an issue you are following:
``
updating the two week release process to update the
fedora-atomic/25/x86_64/docker-host ref
How will versioning work for this? AFAIU right now the nightly compose just uses the
auto-increment feature. Will the stable releases jump numbers (i.e. +14 on every upgrade)?
Though it's probably too late for F25, it might be better to use timestamp based
versions, e.g. `25.20170207`.
building the iso/cloud images from the "updates" ref but
pointing them to the 2wk release ref
> This will mean we can still get new images every night to test but when we release
one of these images it tracks the 2wk ref by default.
I had a chat about this yesterday with @dustymabe and @puiterwijk. One of the proposed
plan of action was to just use `ostree admin set-origin` to make sure the nightlies always
point to the stable repo.
There's a tricky bit here though. We want the new 2wk commits to be children of the
previous commits. But the commits from the nightlies will be on a different branch. When
you e.g. do `ostree commit -b $2wk_ref --tree=ref=$nightly_ref` to promote content between
branches, you will get a different SHA. So the commits on which the nightly images are
built will never actually belong on the 2wk branch (and e.g. `ostree log` will be going up
the wrong ancestry).
It would be better to do to this in separate steps. I.e. promote content to the 2wk
branch, and *then* create an image based on that ref. No `set-origin` needed.
Alternatively, you can also make sure that the nightly composes always commit on top of
the the latest 2wk commit, rather than the previous nightly commit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545