| Re: [AD] Proposal for new branch |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2004-09-04, Peter Wang <tjaden@xxxxxxxxxx> wrote:
> Sure, that page is really out of date. Does anyone else have
> anything they want to add to what I wrote? I don't think I
> explained it that well.
Don't be so modest. You might want to discuss now with Eric about
dictatorship too. Returning to the topic, I will make the future
page have the following text and link it from a news announcement:
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
redesing 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.sunsite.dk/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?
1. Firstly, 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.
2. 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.
3. 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 (link) was announced. Allegro
pro is not designed nor implemented by the Allegro developers.
It is a completely different library started by a user of Allegro.