Re: [AD] de fourium pointium ohium

["Angelo Mottola" <a.mottola@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.

Nice to see these kind of posts every now and then... They make you feel
like there should be a deadline for the 4.0 release, and that's a good thing
IMO.

> 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?
> 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 :-(

I understand there should be some kind of "features freeze", and this
includes pausing immature ports development and focus on bugfixes. As the
author of the QNX port, I feel sad about it, but not that much, as I'm still
under examinations, and I don't even have QNX installed at the moment, nor I
know when I'll be able to reinstall it...
One more thing: from what you say it is not clear if the ports to freeze
include BeOS... IMHO the BeOS port is enough mature to be worth being
included in the "officially supported" platforms, thus it should still be
developed until the 4.0 release. As by now BeAllegro just requires bugfixes,
as all the features are already in.

> 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 can help you if you point me to the right direction, i.e. if you tell me
the exact steps required in generating a WIP.

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

Kernel-like version numbering? Cool, I completely agree!! Guess it was time
someone pointed this out...

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

Humm, this sounds a bit confusing to me... Can you explain better? How
should we do this "binary compatibility" test program?

> 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 :-)

Having a brand new homepage for Allegro would be extremely cool. About this,
I think Grzegorz was working on a new site (or was someone else?), but AFAIK
there have been very slow progresses on that direction, and I think this is
due to the fact a complex site requires time to be created and also to be
maintained.
So I've thought about some possible ways to have a new cool site that can be
easily maintained:
1) We use a script or C program that automatically generates the HTML pages
for us, depending on our needs. Once the program is done, maintaining the
pages should be very easy as it would just be a matter of running the
program again on the server. We could make this to fetch news, add-ons and
other things that can change from a simple text file, thus updating the site
would just mean updating this text file and running the program/script
again.
2) We could use PHP and SQL to create the site, making it easily
maintainable via a web interface. I have experience in this (see my own
site) and I can safely assure this method would produce great results. Only
real problem with this is we'd require a server with PHP and SQL support for
free.

Suggestions are welcomed.

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com