-1 on dropping Life Support for N-1 unless we're ready to shift to rolling releases. That's pretty much the worst of all possible worlds.

Proposed policy: Life Support+

From the date N is released:

• We continue offering OSTree updates for 6 months on N-1
• We do not do "releases" of N-1 in terms of new images, etc.
• We run automated tests (only) on N-1 OStrees once every 2 weeks, when a new N is released.

Running tests on the OSTree means:

1. Install last image of N-1
2. Upgrade to latest OSTree in that series
3. Run whatever automated tests we have

I'd just like to clarify for anyone reading this that "rolling" doesn't mean rolling like rawhide or suse tumbleweed, unless the wheel you have in mind is giant and square and "turns" once each six months when a new fedora comes out.

RHEL and CentOS atomic hosts "roll" from 7.1 to 7.2 to 7.3, etc. The user upgrades w/ atomic host upgrade and there's no rebasing or editing of repo config files required. When we talk about making fedora atomic a rolling release, this is the sort of rolling we're talking about. A very modest (and completely sensible, imo) sort of rolling.

-1 on dropping Life Support for N-1 unless we're ready to shift to rolling releases. That's pretty much the worst of all possible worlds.
Proposed policy: Life Support+
From the date N is released:

We continue offering OSTree updates for 6 months on N-1
We do not do "releases" of N-1 in terms of new images, etc.
We run automated tests (only) on N-1 OStrees once every 2 weeks, when a new N is released.

Running tests on the OSTree means:

Install last image of N-1
Upgrade to latest OSTree in that series
Run whatever automated tests we have

I would prefer not to pretend we support it and would rather have it be clear to the user. What about complex relationships between docker and openshift/kubernetes? What about breakages in releng? What about changes to our processes that we can't/won't change for the older release? All of those things multiply and start to make things more of a maintenance burden. I'd prefer to concentrate our efforts on the existing release (and also prepare for the next release) without having to worry about N-1.

@jbrooks
I'd just like to clarify for anyone reading this that "rolling" doesn't mean rolling like rawhide or suse tumbleweed, unless the wheel you have in mind is giant and square and "turns" once each six months when a new fedora comes out.
RHEL and CentOS atomic hosts "roll" from 7.1 to 7.2 to 7.3, etc. The user upgrades w/ atomic host upgrade and there's no rebasing or editing of repo config files required. When we talk about making fedora atomic a rolling release, this is the sort of rolling we're talking about. A very modest (and completely sensible, imo) sort of rolling.

you and @maxamillion should schedule that VFAD so we can flesh out this :)

+1 on dropping support for N-1, the premise of Atomic Host was to move forward faster and adding legacy Fedora release lifecycle update streams to that seems counter productive.

I'm +1 to dropping support for N-1

In which case: if we're not supporting N-1, then what's the reason to not do a rolling release?

AFAICT, the thought is that rolling is a big disruptive thing, so we need to study it first. We are in fact not supporting N-1 now, so making that official isn't really a big deal.

we just need to agree on what rolling means to us and write it down somewhere. It could mean a lot of different things. The VFAD on this topic should resolve this. Let's not discuss what rolling means to us here.

Let's discuss what "rolling" means here: https://pagure.io/atomic-wg/issue/231

@jasonbrooks I am -1 to make desupporting the old ostree official without at least a plan (and a deadline) to move to rolling upgrades. See #231 for my explanation on why these two issues are inexorably tied together.

I'm going to schedule a meeting for next week to hash this out with the whole Atomic WG that can make it.

One thing we could do that would be pretty easy is to add a new /stable ref as a symbolic link, e.g. we'd do:

ln -sr repo/refs/heads/fedora/26/x86_64/atomic-host repo/refs/heads/fedora/stable/x86_64/atomic-host

Then someone who wants the "follow the latest major" behavior automatically now today could opt-in to it.

One thing we could do that would be pretty easy is to add a new /stable ref as a symbolic link

I like this and would use it myself.

One thing we could do that would be pretty easy is to add a new /stable ref as a symbolic link, e.g. we'd do:
ln -sr repo/refs/heads/fedora/26/x86_64/atomic-host repo/refs/heads/fedora/stable/x86_64/atomic-host
Then someone who wants the "follow the latest major" behavior automatically now today could opt-in to it.

Interesting. Would a rebase still be required? I still think that sticking w/ the supported version should be the default, and you'd instead opt in to forgoing support, but failing that, this sounds nicer than what we have now.

A rebase would only be required one time to track /stable - thereafter it'd be a stream of minor updates, until such time as on the server we change the link to point to the next major.

Basically the client is just going to download whatever the server says.

+1 on dropping support for N-1 releases.

As discussed in the Atomic WG meeting, I've taken a crack at communicating this change:

Future Plans for Fedora Atomic Release Life Cycle

• The Fedora Project ships new releases at ~6 month intervals, and maintains each release for ~13 months. Release X is supported until one month after the release of Release X+2.

• Since the first Fedora Atomic host shipped, as part of Fedora 21, the project has maintained separate ostree repositories for both of the active Fedora releases. For instance, there are currently trees available for Fedora Atomic 25 and Fedora Atomic 24.

• Fedora Atomic sets out to be a particularly fast-moving branch of Fedora, with releases every two weeks and updates to key “atomic” components such as docker and kubernetes that move more quickly than one might expect from Fedora.

• Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree, and dealing with support of the older release on a best-effort basis.

• Starting with either the Fedora 26 to 27 or the 27 to 28 upgrade cycle, the Fedora Atomic Workgroup intends to collapse Fedora Atomic into a single version which will track the latest stable Fedora branch. When a new stable version of Fedora is released, Fedora Atomic users will automatically shift to the new version when they install updates.

• Traditional OS upgrades can be disruptive and error-prone, but due to the image-based technologies that Atomic Hosts use for system components (rpm-ostree) and for applications (linux containers), upgrading an Atomic Host between major releases is little different than installing updates within a single release.

• In both scenarios, the system updates are applied by running an rpm-ostree command and rebooting, with rollback to the previous state available in case something goes wrong, and applications running in containers are unaffected by the host upgrade or update.

• There’s work that must be done to prepare for this collapsed release structure, but for users that wish to opt for this new behavior starting with the upcoming Fedora 25 to Fedora 26 upgrade cycle, we’ll be preparing a “stable” ostree repo location that you can rebase to follow the latest major release. Look for more information on that shortly.

Suggested revision:

• Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree, and dealing with support of the older release on a best-effort basis.

Should be

• Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a "best effort" basis, meaning that the ostree is updated, but there is no organized testing of the older releases.

Suggested revision:

Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree, and dealing with support of the older release on a best-effort basis.

Should be

Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a "best effort" basis, meaning that the ostree is updated, but there is no organized testing of the older releases.

+1

PR for this blog post at: https://github.com/projectatomic/atomic-site/pull/434

jbrooks has published blog post on pa.io http://www.projectatomic.io/blog/2017/06/future-plans-for-fedora-atomic-release-life-cycle/

waiting on fedora magazine post for this (to try to reach broader audience) and then we'll close.

fed mag post here: https://fedoramagazine.org/upcoming-fedora-atomic-lifecycle-changes/