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

[Neil Jerram]

>>>>> "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.

    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.

        Neil