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

Previous Next

Full log

View this message in rfc822 format

From: Greg Hogan <code <at> greghogan.com>
To: Noé Lopez <noe <at> xn--no-cja.eu>
Cc: 72840 <at> debbugs.gnu.org
Subject: [bug#72840] [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.
Date: Thu, 12 Sep 2024 11:39:58 -0400

On Wed, Sep 11, 2024 at 2:33 PM Noé Lopez via Guix-patches via
<guix-patches <at> gnu.org> wrote:
>
> – There is no policy for updating packages through major versions, IMO
>   this should be the same as deleting and the previous version should be
>   kept for a while, at least for the time for dependencies to update
>   upstream.

Internal package conflicts result in broken builds. External dependent
projects can simply remain on their current Guix commit and delay
upgrading until compatible with the updated API.

> >+If the package being removed is a ``leaf'' (no other packages depend on
> >+it), it may be removed after a @b{one-month review period} of the patch
> >+removing it (this applies even when the removal has additional
> >+motivations such as security problems affecting the package).
>
> – Why do « leaves » get removed at all? The dependents could be
>   users that installed it in their profiles or manifests, one month
>   seems very low.

If a package has failed to build for and not been updated in a long
time then who would be using it? The package source will be available
in the git history in case someone would like to resurrect it at a
later time.

Greg

Previous Next

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