[AD] de fourium pointium ohium

[Peter Wang <tjaden@xxxxxxxxxx>]

This post is quite big and perhaps premature, but I'm going to let
loose some thoughts I've had about The Big One.  Much of this has
been brought up before by other people.  Hopefully everyone will
chip in their ideas.


Timeline:

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?

[the rest of this post assumes that target]

To make it by the end of the year, I think the QNX and Mac ports
will have stay "unsupported".  The respective port authors might
disagree.  Ideally, leading up to it (i.e. from now on), we need to
rope in people to periodically compile the CVS tree on BeOS, Mac and
QNX.  Breakages there tend to get unnoticed :-(

We need to also cut down on big changes.  Easier said than done (see
especially 3.9.37, and there's more pending), but I think we've got
three or so WIPs up our sleeves (unless someone else wants to take
that task off my hands (please!)).  We should keep that in mind.

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.


Version numbers:

The version numbers are going to be more important, because of
binary compatibility.  I'd like to see a Linux kernel style version
numbering, in the form of "major.minor.release".  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.

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

If we follow the Linux kernel, even minor versions would be stable,
while odd minor versions would be for development.  So if we wanted
to add functions that appear in 4.2.x, we would put it into 4.1.x in
CVS for testing.

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.  Maybe we could reserve odd revision
numbers for the CVS versions of stable branches, and use even
revision numbers for proper releases.  Too confusing?


Binaries:

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

Under Linux, we should be able to produce *real* binary RPMs now,
and add-your-favourite-package-format-here (tgz for me).

Under Windows, we should probably officially "bless" one particular
set of DLLs, so everyone can have exactly the same thing, no matter
what compiler they use.


Web site:

We need that new web site installed before 4.0 is out.  I don't
think that's a problem though.  allegro.cc is also a great resource.
We might just have a snowball's chance in hell of synchronising the
release of 4.0 with the new allegro.cc :-)


That's all (for now) folks.

-- 
tjaden@xxxxxxxxxx - http://www.alphalink.com.au/~tjaden/
PETROOL (PET rul), n.  The slow, seemingly endless strand of motor oil at
the end of the can.  -- Rich Hall, "Sniglets"