Re: Should we move/copy/symlink ice-9/srfi-8.scm to srfi/srfi-8.scm?

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> >>>>> "Marius" == Marius Vollmer <address@hidden> writes:
> 
>     Marius> Neil Jerram <address@hidden> writes:
>     >> 1) Very easy at release time to go through the code and know
>     >> which bits of old deprecated stuff to remove completely.
> 
>     Marius> We have the log in RELEASE already.  Assuming that it is
>     Marius> maintained properly, wouldn't it suffice and provide still
>     Marius> more information about what to do?
> 
> Yes, but it's not very immediate.  Given the right mechanisms - such
> as specified in your other post on deprecation - we could choose to
> manage all deprecation state as part of the code and not bother with
> maintaining this information in RELEASE.
> 
> The argument sort of parallels the one about having docstrings as part
> of the code versus having docstrings stored separately.

Hmm, I see it more in parralel to having ChangeLog files and
documenting changes in the code itself.  With a ChangeLog, we have a
central place to document changes.  This central place allows us to
put isolated changes into context, and add commentary that applies to
many places in the code at once.

With RELEASE, we have a similar thing.  It allows us to see the whole
deprecation state in one place.

I would rather keep it the way it is, simply for avoiding changing a
tradition that I don't think is broken.

>     Marius> What can we do to increase people's aware of RELEASE?
> 
> If we decide to keep deprecation state in RELEASE, perhaps we need to
> force people to read it by creating a `warn and fail' value for your
> GUILE_WARN_DEPRECATION proposal, and making `warn and fail' the
> default for everything that is planned to be removed in the next Guile
> release.

Hmm, RELEASE is mainly for people doing releases of Guile and people
hacking on Guile itself, while the deprecation warnings are for people
using Guile.  I don't see the benefit of mentioning RELEASE in a
deprecation warning.

What I meant with increasing the awareness of RELEASE is, how can we
make sure that all features that are deprecated are properly listed in
RELEASE so that we can find them?  The procedure is already documented
in HACKING, which ought to suffice, no?