Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
]] Andreas Beckmann
> On 2017-03-09 18:00, Ian Jackson wrote:
> > To be fair to Pirate, Andreas Beckmann suggested #856606 that if
> > Pirate disagreed with Andreas, Pirate should go to the TC.
> The disagreement between Pirate and me is not about the RC-ness of
> #856606, but more about the general requirement of working upgrade paths.
> This is my understanding of Pirate's point:
> "Package P hasn't been part of any stable release so far, therefore
> upgrades from earlier package versions don't have to be supported.
> So not having a working upgrade path from version 1.2-3 in testing
> to version 1.2-5 unstable is not a bug."
>From reading through the bug log, that is my understanding of his point
The upgrade is from a previous version of gitlab that has been in
stretch for a little under a month (it went into testing on
2017-02-18). I think it's completely clear that failure to support
upgrades (even between short-lived versions that only hit unstable) is a
bug. For versions that hit testing, even more so.
In the typical cases where we don't support upgrades between major
versions (think apache 1 → 2), we typically renamed the packages
involved. That seems overly heavy-handed in this case where the upgrade
path can just be fixed (see mail from Phil Hands for some suggestions),
but it points to what the bar is.
The guidelines are more lax for experimental where people have been
known to not make it possible to move to testing/unstable versions of
the package without reinstalling/reconfiguring it. I think this is, and
should be, discouraged but allowed. Experimental exists for a reason:
to be able to conduct experiments, and sometimes you need to burn the
experiment to the ground afterwards.
> I didn't find anything in the policy about upgrade requirements ...
> but I think there is a general agreement that direct upgrades must work
> (and only skipping over stable releases is not supported).
There are a lot of requirements for packages that are not written in
policy. There's no requirement in Policy as written that changelogs
must be in English, for instance.
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are