|
|
The future
Allegro has evolved into something fairly big, really nice and
extremely useful, and some dust has now settled since version 4.0
was released. The library has thus reached that point where every
little addition or modification may have side effects on the whole
library: now that we have gone multi-platform, it's not so easy to
add features which are available everywhere.
By the end of 2002, the Allegro developers decided to redesign
the API and implement it from scratch. This was a very ambitious
process which spawned a (now closed) mailing list for discussion
of new features and an archive (http://alleg.sourceforge.net/future/info.html, there's a
cache at http://allegro.dotsrc.org/future/info.html) with proposals on how the next
version of Allegro would look like.
Unfortunately, due to lack of time, this approach did not work
out. Instead, we have decided on a different approach. The API will
be redesigned in pieces and each piece will be implemented within
the current Allegro codebase. This work has begun, and the changes
will be seen from Allegro 4.4 onwards. What does this mean for users?
- We intend to maintain backwards compatibility with the current
Allegro API (except for some obscure features). Most of the time,
this will be done using a compatibility layer -- the old API will
be layered on top of the new API.
- Users will be able to use the new API as it becomes available --
if they want to. Or they can wait until the entire API has been
redesigned and implemented before adopting the new API.
- Even when the entire API has been redesigned, we will probably
retain the compatibility layer for the current API, because it
would be easy to do so.
On a related note, in June AllegroPro (http://home.comcast.net/~Korval/) was
announced. AllegroPro is not designed nor implemented by the Allegro
developers. It is a completely different library started by a user
of Allegro.
|
