RFC: Flatpak application versioning: rolling stable

The Fedora today, there was a presentation about a vision for how
applications should have a different life cycle than the operating system:

<a href="" title=""></a>

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

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
* 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

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 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

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