short-tem release plans

[Alexander Larsson]

On Tue, 2017-08-15 at 13:44 -0400, Simon McVittie wrote:
> On Tue, 15 Aug 2017 at 16:58:37 +0200, Alexander Larsson wrote:
> > There are a few things I want to add that will make it
> > easier for flathub, and there are some minor bugs I want to fix.
> > But I
> > think we can get 0.10.0 out in a couple of weeks, and after that
> > the
> > plan is to continue work on the 0.10.x stable branch.
> > 
> > This means after 0.10.0 we can only do fixes and backwards
> > compatilble
> > changes.
> 
> From the point of view of downstream distributions (Debian in my
> case) I
> would prefer it if significant new features, even if backwards
> compatible,
> went into a 0.11.x branch. So far I've been able to get 0.8.x past
> the
> stable release team, but some of the changes were at the upper end of
> what I feel I can justify for a stable update; so it would be easiest
> for me if 0.10.x was bugfix-only, at least as strictly as 0.8.x.

Its a lot of work to keep an extra branch though, and it makes it
harder for it to reach people. There was very much a gain in being
allowed to be more gung-ho about e.g. manifest backwards compatibility
in 0.9.x, but at the same time you can't expect a lot of people to run
it if its breaking things.

So, I'm thorn on this. 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.

For instance, lets say we do some feature work for two minor releases,
meaning we'll have 0.10.0, 0.10.1 and 0.10.2 which are backwards compat
but may have some new features. Then after that all new features go in
0.11.1 and 0.10.3 is a security/bugfix only release.

Would that make you less hesitant?


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a short-sighted gay jungle king on the hunt for the last specimen of 
a great and near-mythical creature. She's a plucky Buddhist snake charmer 
from a different time and place. They fight crime!