short-tem release plans

[Simon McVittie]

On Wed, 16 Aug 2017 at 10:54:07 +0200, Alexander Larsson wrote:
> Its a lot of work to keep an extra branch though, and it makes it
> harder for it to reach people.

Yes, I understand this point of view. If you wanted to go to a
systemd- and ostree-like model where there is no upstream bugfix-only
branch at all, then that would also be OK; but then you would have to
live with the versions in e.g. Debian, Ubuntu LTS, RHEL, SLED being
essentially random, with whatever backported fixes for serious bugs
those distro maintainers are able to get past their respective
release managers.

> I have a proposal though:
> 
> 0.10.0 and further 0.10.x releases are ABI/CLI/file-format stable,
> meaning a script that calls out to flatpak, or a working builder
> manifest will always continue working. Distributions that are not meant
> to be super-duper-stable-wont-change-in-5-years should feel safe to
> package and update this. Further work will initially happen on master,
> and there will be no initial 0.11.x unstable branch.
> 
> However, over time the 0.10.x work will slow down, and changes will
> queue up that are more risky or affect compatibility, so eventually we
> will make master a 0.11.x unstable branch and create a 0.10 branch for
> 0.10.x. At that point we change the policy for 0.10.x into a backport-
> fixes-and-security-issues similar to the current 0.8 policy, which
> should be good enough for the likes of debian stable and rhel.

This sounds OK. However, because Debian testing/unstable is essentially
the work area for preparing stable, I can only put 0.10.x in Debian
testing/unstable if either: you are confident that it will reach the
bugfix-only policy well before we freeze; or you accept that the next
Debian stable will not necessarily be able to track 0.10.x. Going to
bugfix-only any time in the next year is definitely fine for Debian,
although I can't speak for Ubuntu LTS (their release schedule is out of
phase with Debian's).

    S