Re: [AD] de fourium pointium ohium

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> At one stage I mentioned that I thought we should release 4.0 at or
> before the end of the year.  What's your evaluation?

I propose December 10, 2001 as the release date: exactly 4 years
(Oh My God ! (tm)) after the 3.0 release, according to the most recent file
in the alleg30.zip archive.

The DOS port is virtually frozen now.

The last showstopper bug for the Windows port (new joysticks not properly
working) was supposedly fixed in the latest WIP release. It would be nice to
have a DirectInput-based joystick driver, but I don't think that's really
mandatory. And ideally we could make sure that the 4.0 version runs right
out of the box under Windows XP.

> We need to also cut down on big changes.  Easier said than done (see
> especially 3.9.37, and there's more pending)

Really (apart from your pthread timer for Unixes) ? The only big one I can
see is the timer/thread API. I think we ought to quickly make a decision
about it.

> I think it would help if there was a new section in `todo.txt'
> called "Definitely After 4.0", and all new features (and most of the
> current things in the "Wishlist") would go in there.

Why not rather use a [4.0] tag for the "required" todo items ?

> Obviously the major version will be `4' for the rest of our lifetimes,
> so the minor version and revision numbers will be the meaningful parts.

Don't be that pessimistic !
It's up to you to notify your grand-son of Allegro ;-)

> I thinking that all DLLs (etc.) with the same minor version should
> be backwards compatible (e.g. 4.0.2 can take the place of 4.0.0).
> Thus we can't remove any external symbols without incrementing the
> minor version.

I agree and I propose "allegmajorminor.dll" as the DLL name.

> There may be restrictions on internal symbols, too
> (e.g. ordinals under Windows, the unsharable part under Unix, etc.).
> Adding symbols may or may not be a problem, but I think it should be
> avoided, especially public ones.

I'm going to commit the new DLL export file generating script: it will
ensure binary compatibility for the DLL interface as long as we don't remove
symbols.

> Another thing is, for a while we had a problem where people
> distributed binaries built against CVS versions, which didn't work
> with DLLs built from WIPs.

I got caught by this problem: fixdll.bat may use the DOS sort.exe utility
instead of the GNU one. And of course the two sorts don't agree about the
sorting order !!!
Ultimately I think we'll have to remove fixdll.bat and keep only fixdll.sh .

> We need to write something like a test suite to check if one release
> is binarily backwards compatible with a previous one.

We have already many examples and test programs, but you're right.

> That's all (for now) folks.

Tennis (Wimbledon I suppose ?) seems to be very inspirative  ;-)

--
Eric Botcazou
ebotcazou@xxxxxxxxxx