The Fedora today, there was a presentation about a vision for how applications should have a different life cycle than the operating system:
For Flatpaks, the future is now - as soon as we start building them, I'd like to start immediately in a model where the application lifecycle is not tied to the traditional release cadence.
My basic idea is that applications consumed as Flatpaks should have a "rolling stable" model - there is a *single* default version of the application for all Fedora users, and that version is the latest upstream stable release (once the Fedora Flatpak has passed automatic and manual testing.)
In more detail:
* The rolling stable version is maintained as the master branch of modules/MyApp (this git repository contains both the module definition and the container definition) - this also ends up as the stream of the built module
* It should use the Flatpak runtime corresponding to the latest stable release of Fedora - e.g., flatpak-runtime:f28 at the moment.
* The Flatpak branch name should be "stable", to correspond to Flatpak conventions
Questions, possible answers
======================
Isn't 'master' == 'rawhide' == unstable?
This is certainly the Fedora tradition, but since the stable branch is the *default* branch, and since it will often be the *only maintained branch*, I think it works better on master.
What about packaging *unstable* upstream releases?
If the packager desires, they can create a 'devel' branch, but they need to rename the application in the desktop file and rename the application ID, so that the devel releases can be parallel installed with the standard releases. [There's some work that needs to be done to enable this either in Bodhi since currently both branches of MyApp will end up tagged by Bodhi as MyApp:latest with the latest updated one winning.]
What about packaging old stable upstream releases?
This should be done only in exceptional circumstances, such as a complete rewrite upstream that produces a new stable version that (at least originally) doesn't have all the features of the old stable version. In this case you would use a upstream-versioned branch in dist-git, and also be expected to change the desktop file name and application ID to enable parallel installs.
How does this affect rpms/MyApp
The branch structure of rpms/MyApp does *not* have to match that of modules/MyApp. If a new major release of MyApp comes out in the middle of F29, the package maintainer would have various choices a) ask for a stream branch of rpms/MyApp to put the new version on and change their module to reference the stream branch b) update the f29 branch to the new major version and upgrade rpm consumers as well c) update the master branch to the new major version and change the module to reference the master branch - the spec file would need to work against both the f29 and f30 platforms, but that usually isn't hard.
How does this relate to server containers?
I
registry.fedoraproject.org/MyContainer:latest should be "rolling stable" in the same sense. It should be the latest upstream revision, and should be based on the latest Fedora release. But server admin's often don't want to wake up one morning with their apps upgraded to a different major version (or wake up one middle of the night to a phone call), so perhaps we need to have stream branches and tags *up front* - so that you can use MyContainer:10 [needs the same Bodhi work referenced above to avoid fighting over 'latest' and 'testing']. We'd also need to figure out when it's permissible for a stream branch to rebase to a different Fedora base image.
Do you have documentation for how Flatpaks will work?
Nothing very up-to-date. I hope to have comprehensive Flatpak packager docs posted within the next few days, hopefully they will clarify this a bit