Brett Lymn wrote:

> According to Ross Harvey:
> >
> >The libcurses update done on 4/13 was INCOMPATIBLE with all previous
> >versions and will BREAK some old binaries.
> >
> 
> This is a bit over the top.  Have you actually seen the diff to fix
> the pr you reported?  It was a change of the WINDOW structure - moving
> one int to the end to make the memory layout the same as it was
> before, only longer.  The fact that vi grovels through the curses
> internal data structures is somewhat of a concern to me.

Umm, in the case vi was calling "clearok()", which is a macro that
grovelled a curses data structure.  It wasn't vi's fault.  If I were
doing curses from scratch, I don't think I'd use macros to do this
grovelling because you _are_ tied onto the same data structures ~forever
to maintain binary compatibility.

> >The libcurses update done today, 6/28 is INCOMPATIBLE with the update done
> >4/13;
> 
> True, it will but you cannot have it all.
> 
> > hopefully it will restore compatibility with 1.4 and earlier,
> 
> I believe it does - it certainly fixed the problem quoted on the PR
> you raised.
> 
> > but it
> >will BREAK binaries compiled between 4/13 and 6/28, modulo actual installation
> >of the new bits.
> >
> 
> True but as I said you cannot have it both ways with this problem.

My take on this is that it would me more important to have binary
compatibility between releases.  This may involve some pain for -current
users, which obviously we want to minimise.

> >	1. When you apply 3,500 lines of patches to a shared library, post
> >	   a note about it here.
> >
> 
> Ross, I put a PR in to update curses fully 6 to 9 months BEFORE this
> patch was applied.  Apart from bug fixes to the original PR the code
> was substantially the same.  I did post messages about the PR multiple
> times over the period after I submitted the PR.  What more could I do?
> 
> >	2. If you do something like that, actually TRY IT first on old
> >	   binaries.
> 
> You presume we did not.  This is not the case.  The code that was
> submitted as a patch was tested by a few people prior to the import of
> it into the tree.
> 
> > And don't change the field layout of structures that
> >	   are implicicitly part of the API.
> 
> This is true  - mea culpa.

In this case, they're part of the implementation, not the API.
Unfortunately that sucks, but we have to deal with it.  Leason
learnt the hard way.

> >	4. When you intentionally introduce an incompatibility, even if it's
> >	   to correct a previous incompatibility, post a note about it here.
> >
> 
> I shall talk to the other guys about this - I found the bug last
> night, stomped it and sent a message to the curses development guys
> about it.  I was not expecting it to hit current quite that quickly.

I found the bug (I think about a 1/2 hour before you did) and committed
a fix.  That's why -current knows about it :-)  In retrospect, I should
have sent an announcement to current-users about this.  To be honest,
it was getting late last night when I found the problem and I was just
happy to have found and fixed it.  "Live and learn."

Simon.