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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Janneke,

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>>   https://issues.guix.gnu.org/72840
>
> Thanks, looks good to me!  As a side remark: It would be nice if
> upgrading of config.scm / home.scm could be automated.

It would be great, indeed.

> Anyway, I do have a vaguely related question.  The Dezyne package comes
> with a `guix.scm' that uses a package description in
> guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'.
>
> Recently, %gnu-build-system-modules was deprecated in
>
> 28dbfdb38f52f5814fb4cba9c02831d2ab0dc079
> build-system/gnu: Introduce ‘%gnu-build-system-modules’ deprecated alias.
>
> 9e4ce281dbd92e3c52b831824ebb1f77023c960c
> build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-modules.

I’m not convinced this was a worthwhile change BTW, looking at the
intended clarity improvement vs. cost ratio.

> Although the `guix.scm' has a comment like
>
> ;; To use the canonical commit that has everything prebuilt:
> ;;
> ;;   guix time-machine --commit=918b7d102c2051c3d6c6ba54c8d265affec5282c -- shell
>
>
> documenting a commit that can be used for building the package and has
> substitutes available, usage of the commit is not enforced.  After a
> recent `guix pull', we now get this warning
>
> pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, use '%default-gnu-imported-modules' instead
>
> and I'm wondering what the best moment would be to change the package
> description.  Upgrading sooner (i.e., now) means that a future guix that
> has this deprecated feature removed will be able to build more
> hystorical releases of the package simply by doing `guix shell', so
> that's probably the best choice?  It would mean that all developers have
> to upgrade now (or use the time machine).

Yeah, that’s always a difficult choice, and I don’t have a good answer.
What’s sure is that the deprecated name will remain available for a
relatively long time, so there’s no urgency at this point.

> but you'd have to know about that and it probably only works for the
> Dezyne package.  Is there a better way or should something like this be
> advertised/recommended in the documentation?

I’m not sure we could recommend one approach that would work for
everyone because it really depends on the use case (for instance whether
building with an older Guix is important for your project.  But at
least, by setting expectations, the deprecation policy lets users making
informed decisions.

Ludo’.