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

[Javier Jardón]

Hi Emmet,

Thanks for the feedback

On 16 July 2018 at 20:00, Emmet Hikory <persia at shipstone.jp> wrote:
> 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.

Sorry, by "API build breaks" I mean software that build fine but stop
building with a new version of GCC
Not sure what is the correct term to use in this case

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

Anything that contradicts the previous point: the update is an API
break, or an "API build break"

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

Problem here are not the ABI breaks, but more the "API build breaks"
(new GCC will probably break some flatpak
apps that build perfectly fine with previous versions of GCC, so we
can not upgrade GCC in the stable branch)

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

We will provide a minimum of 2 years of security updates, a branch
could be maintained for longer
if there is demand for it (as suggested, we can create a LTS release eventually)

In this case the number of releases to maintain will be 4, but in this
case we would expect help for more
parties for the maintenance of the LTS release. Maybe we should remove
the "maximum" in the
"We maintain maximum 3 releases at any given time" sentence to avoid confusion

Cheers,
Javier Jardón