Subject: Re: curses strangeness, Cannot fork messages
To: None <firstname.lastname@example.org, email@example.com>
From: Ross Harvey <firstname.lastname@example.org>
Date: 06/28/1999 12:43:46
> From email@example.com Mon May 31 22:02:32 1999
> From: firstname.lastname@example.org (Brett Lymn)
> Subject: Re: curses strangeness, Cannot fork messages
> To: email@example.com (Gary Duzan)
> Date: Tue, 1 Jun 1999 14:21:44 +0930 (CST)
> Cc: firstname.lastname@example.org
> According to Gary Duzan:
> > A quick update: a newly compiled sc executable works. Perhaps
> >there should have been a major number increase, or maybe the
> >__RENAME() hack.
> It should not have been necessary because the calling interface did
> not change per se. We simply extended the functionality. Perhaps
> there was a function name clash....
Regarding: > "We simply extended the functionality".
Seeing as how you've verified this and other bug reports, perhaps a retraction
and a warning is in order? Something like this...
** WARNING **
The libcurses update done on 4/13 was INCOMPATIBLE with all previous
versions and will BREAK some old binaries.
The libcurses update done today, 6/28 is INCOMPATIBLE with the update done
4/13; hopefully it will restore compatibility with 1.4 and earlier, but it
will BREAK binaries compiled between 4/13 and 6/28, modulo actual installation
of the new bits.
Some suggestions for the future:
1. When you apply 3,500 lines of patches to a shared library, post
a note about it here.
2. If you do something like that, actually TRY IT first on old
binaries. And don't change the field layout of structures that
are implicicitly part of the API.
Vi(1) breaks immediately in an obvious way, it wouldn't have
been hard to uncover this botch.
3. When you discover/verify a serious incompatibility, post a note
about it here.
4. When you intentionally introduce an incompatibility, even if it's
to correct a previous incompatibility, post a note about it here.