GNU bug report logs - #72840
[PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

Previous Next

Full log

Message #42 received at 72840 <at> debbugs.gnu.org (full text, mbox):

From: Konrad Hinsen <konrad.hinsen <at> fastmail.net>
To: 72840 <at> debbugs.gnu.org
Subject: Deprecation policy
Date: Wed, 11 Sep 2024 21:49:26 +0200

Hi everyone,

It's good to have an explicit deprecation policy, thanks for writing
this!

Overall it looks good. I share Noé's concerns about breaking changes in
packages. If removing a package is subject to the deprecation policy,
then updating a package to an incompatible version should be handled the
same way. But it is of course much more difficult to detect, for the
packager and even more so for the Guix maintainers.

There's also a use case missing in the list in the beginning: Guix as a
dependency of some other software, which in the worst case is no longer
maintained. Users of such software may not even be aware of depending on
Guix, and thus not follow Guix news at all. The number of such programs
is probably close to zero right now, but I bet it won't remain
zero. Every piece of software becomes someone else's dependency one day,
at the latest during the next metasystem transition (see the last part
of my talk in Montpellier last year
(https://hpc.guix.info/events/2023/workshop/program/#caring-for-your-environment-s-)

This is certainly not an urgent problem, but an interesting one, so
worth thinking about.

Finally, I wonder about the practicalities. Who will watch out for
potential violations of this policy, and how? It doesn't look like an
easy task. In particular detecting "user-visible incompatible changes".

Cheers,
  Konrad.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.