[Freedesktop-sdk] ABI stability and release model

[Tristan Van Berkom]

Hi all,

It was raised recently by Cameron on this list that there are some
problems with ABI stability which effectively break things for end
users.

Asides from this, I think it is also worth considering concerns about
overusing end users bandwidth (to install new updates) and similarly,
the churn and compute resources we impose on downstream projects who
need to rebuild as a result of releasing new things frequently.

As this is all related to the current release model, I think we can
more effectively resolve these issues if we take a step back and
reexamine our release model and consider its side effects.

Related links can be found at the end of this mail.


Broken ABI stability
~~~~~~~~~~~~~~~~~~~~
This issue Cameron has highlighted is quite specific and in depth, so
instead of discussion that directly, I would prefer to boil this down
to a simpler hypothetical example that is easier to digest.

  A.) End user installs a Flatpak, and the current 18.08 release
      of the freedesktop-sdk runtime is also installed.

  B.) Upstream freedesktop-sdk releases a new 18.08 release, which
      is fully backwards compatible.

      In this new release of the runtime, new features/symbols are
      added in some libraries.

  C.) A new Flatpak is built against the new 18.08 release,
      and this application uses some of the new symbols in libraries
      which were introduced in the latest 18.08 release.

  D.) The end user installs this new Flatpak.

      When the user tries to run this flatpak, the application cannot
      be loaded because the user's runtime does not contain the new
      symbols which are required by this new application.

To compound matters further, in Cameron's case we are talking about an
extension point that is released directly from freedesktop-sdk, which
needs to function when combined with the KDE runtime, which has not
been rebuilt and released yet - which means that even if the user had
wanted to update to a new runtime, a new runtime was not available to
the user at the time.

To summarize my understanding of the current setup:

  o Runtimes, applications, and extension blobs are all distributed
    separately.

  o These rely only on the "18.08" version (either directly or
    indirectly via a derived runtime like GNOME/KDE) to indicate that
    these components are intended to function properly when combined
    together on an end users' system.

  o Our current model which considers backwards compatibility only,
    allowing addition of new symbols in the same 18.08 version of the
    runtime.

    This means that it is possible to install incompatible combinations
    of the Runtime/App/Extension tuple.


My thoughts are that on our side, we must provide a guarantee that a
user cannot install an incompatible runtime/app/extension combination.

Am I missing some important details ?

What does the community think about this, what should we do to ensure
that we don't break end users ?

Cheers,
    -Tristan


PS: Some links to related discussion follow here...


Our documented release model:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/release

Ensure ABI stability of extensions:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/669

A lot of discussion in the above is on the associated merge request:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/1031

Cameron's mailing list report of ABI break:
https://lists.freedesktop.org/archives/flatpak/2019-February/001482.html

Make releases less often:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/674

Avoid adding new elements in stable branch which are exposed in
platform/sdk:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/689