[Freedesktop-sdk] Release cadence and maintenance plans of freedesktop-sdk runtime

[Emmet Hikory]

Javier Jardón wrote:
> After some discussions about different approaches, we would like to
> share our current plan for the future freedesktop-sdk flatpak runtime
> releases
> 
> Note this is not set in stone yet, so please provide feedback or ask
> any questions you can have!
> 
> - When a new stable release release is done, the changes on that branch
> will only be:
>   - security updates
>   - stable releases (tested carefully); no ABI breaks / API build
> breaks.

    For ease of writing, I think it safe to only say "ABI breaks": any of
the class of API change that can break a build is surely also an ABI change.

>   - we will try to keep updating that branch as much as we can,
> branching only if necessary as previous point

    Could you expand on when it might be necessary to cease updates?
Often new releases of software can be backported to be ABI compatible
with earlier releases, but obviously there is a threshold at which point
at which this is no longer sensible.  I'm hoping for some guidance on
how that point is to be determined.

> - We release a new major release every year, _only_ if:
>   - There is a ABI break with any new component
>   - There is a "API build" break (apps might not compile because new
> major releases of important packages (GCC))
>   - Looking at the GCC and other major project cadences, this is likely
> going to happen.

    Every year seems very often to me.  In the case of gcc, I can only
remember two or three ABI changes in the last decade (ignoring the
special cases where some group selected an alternate ABI for a
specific architecture).  Although there are many advantages to time-based
releases, maybe a longer time period would be possible?  Alternately,
perhaps the threshold for release could be based on some metrics related
to the number of components that are held up for ABI transition?

> - We will only maintain the current stable release and the previous
> one, this means:
>   - Stable releases get minimum 2 years of security updates
>   - We maintain maximum 3 releases at any given time:
>     - Development
>     - Stable
>     - Old stable

    This seems a sensible policy, but there is no space between
"minimum" and "maximum" as used above on a yearly release cadence.
With a longer release cadence, the "minimum" and "maximum" have
more meaning.

-- 
Emmet HIKORY