Re: Debian's branches and release model
Thomas Goirand dijo [Wed, Oct 20, 2021 at 10:51:59PM +0200]:
> >> That's obviously what I'm doing. But when there's 2 releases during the
> >> freeze, it means one of them will never reach Unstable.
> >
> > Right, which makes perfect sense.
> (...)
> > I guess very few will, but if it's needed, it's available -- and
> > the work for you when the freeze is done is much smaller (just
> > re-target changelog, re-build, re-upload).
> >
> > What do you lose by those uploads not reaching unstable?
>
> Very simple: an upgrade path. In most OpenStack projects, you cannot
> skip an OpenStack release, at least because of the db schema upgrades.
Uff, that sounds quite ugly :-(
...And what about providing Openstack packages whose name includes the
version, as Linux or PostgreSQL do? that way, if OpenStack releases
twice a year and Debian every two years, Debian X can include the four
OpenStack releases that have happened since Debian X-1... Or you can
continue running your previous OpenStack release if you so want, for
some extra years. It would be up to the sysadmin to jump from
OpenStack a→b→c→d before upgrading to Debian X+1 (which ships with e,
f, g, h).
It seems as very little gain for the huge framework that OpenStack
is. Now, OTOH, distribution maintainers could work together to pick
migrations. If you can pick all the needed bits from the d→e migration
and apply them in your postinst (if upgrading from d to f), you can
effectively skip going through e.
Of course, picking the migrations for every OpenStack release could
allow you to build intelligent (although probably obese) maintainer
scripts able to perform the needed updates you have, a→d, d→g, etc.
I guess I'm just stating obvious bits... and that the OpenStack
complexity would make this obviously harder. But if the process is
automatizable, it is doable (of course, with enough developer
resources). And fleshing out the needed migrations would benefit not
only Debian, but every distribution carrying non-consecutive OpenStack
packages.
Reply to: