One of the very nice things about preupgrade going away was that we no longer had to mess with this manually updated file. ;(

One possiblity (although it would still require some changes) is to look at the metalink mirrormanager has for the install images.

For example, fedup currently looks at:

https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-install-21&arch=x86_64

(or whatever arch) for a list of mirrors to get the install images from.

In the last cycle we updated that before 21 was released, but perhaps we could look at not doing that until it's out and you could use the existance of those mirrors as a key. Or we could update it for Alpha/Beta, but you could see the Alpha/Beta in the links to know it's not final?

I'd really prefer if we come up with a way to do this that avoids a manually updated file if we can at all.

I'm fine with any mechanism, as long as it is reliable and avoids premature notification - just looking for the repository with the right name on the mirrors has the downside that we a) need to hardcode details about the directory layout and b) it might show up before the release is officially out (as you say, that happened for f21).

What about the .treeinfo file that is used by fedup as part of the upgrade process? There's an example here

https://dl.fedoraproject.org/pub/fedora/linux/releases/21/Server/x86_64/os/.treeinfo.signed

If the URL are really stable, maybe relying on pkgdb could be an option?

Collection that are 'Under development' are the non-released branches, 'Active' are the current one and the old ones are 'EOL' and pkgdb should have the required information about the name of the collection for yum, no?

https://admin.fedoraproject.org/pkgdb/api/#list_collections

In next-gen compose tools, some dependency ordering and fedmsg tie-in may be possible to kicks off correct tasks at the right time. So for instance, if there's an approved compose, and that gets marked in some way, it could trigger the creation of such a file too. threebean and I had tossed around an idea of doing this with some sort of systemd/container based solution so it doesn't have to become a human's job to figure out and debug the ordering constantly.

I propose we use a keyword like ''next'' for ideas that should be covered in such tools. I'm not saying those are infinitely far off, either. I'm having some preliminary discussion with dgilmore & pbrobinson on how the Fedora Engineering team can pitch in to help with these tools and the process by which they're developed and tested for rel-eng use in production.

I'm going to go ahead and tag this with keyword ''next'' with the understanding that other people may have better (or even just more immediate) ideas, and my intent is not to block those ideas. This note is more to provide a reference point to help gather inputs.

So, can the requestors here see if the pkgdb api in comment 4 will meet their needs?

Thats best from my point of view as manually updating a file is prone to failure and means there's another place instead of getting all that info from one place.

Replying to [comment:6 kevin]:

So, can the requestors here see if the pkgdb api in comment 4 will meet their needs?

Thats best from my point of view as manually updating a file is prone to failure and means there's another place instead of getting all that info from one place.

Richard and Kalev both said that this would be fine, gnome-software can easily use this as a datasource.

https://admin.fedoraproject.org/pkgdb/api/#list_collections is nice, but it doesn't include any dates. For dnf-system-upgrade-plugin it would be nice to be able list Active releases along with their planned EOL date.

At least the starting date should be easy: it could be recorded as the moment when some release is switched to status=active. Maybe the planned EOL date could be entered at the same time...

We will not be updating releases.txt if you need more from pkgdb please file a RFE with pkgdb. however a release is marked active in pkgdb when we enter final change freeze so thats not a suitable date. we would need to have a way to update the ship and eol dates.

Replying to [comment:9 ausil]:

However a release is marked active in pkgdb when we enter final change freeze so thats not a suitable date. we would need to have a way to update the ship and eol dates.

We're changing pkgdb to avoid this, Active will be the release day and we'll have a different flag to prevent retiring packages at any time we want (ie: final change freeze).

https://fedorahosted.org/pkgdb2/ticket/49