Re: [AD] to prefix or not to prefix (sigh)

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

Peter Wang wrote:
> [begin rationale; skip this if you want]

Good, this is exactly my viewpoint as well.

> * 4.0: The old, non-prefixed API.  

Good, I think we must keep this.

> * 5.0: The API will be the same as 4.0, but with prefixes.  

This pretty much requires a new name for allegro.h and liballeg.a,
because people may want both 5.* and 4.0 installed at the same time.
What about allegro5.h and liball5.a ?

> * 5.2: The prefixed API, with new features.  Once people are used to
>         the new API, we would release this.  {Once this is out, 5.0
>         will be in the same state as 4.0 (i.e. maintained but not
>         developed), unless 5.2 provides some sort of 5.0 compatibility
>         mode (then it would kill off 5.0).  Stuff like the 8-bit
>         palette would go in here, rather than 5.0.  

This is IMHO the best proposal so far, except: why do we need this
two-step thing (first prefix, then add more API-breaking stuff)? I think
it seems easier if 5.0 is more like a WIP: As soon as the prefix thing
works, we immediately introduce everything else that breaks the API,
e.g. 8-bit palettes. I don't understand why anybody would want to
upgrade to 5.0 but not to 5.2 if the only news in 5.0 is prefixing. The
point is that we don't need to maintain yet another branch if we keep
the time gap between 5.0 and 5.2 as short as possible, and regard 5.0
more as a WIP than as a stable release.

Btw, we could at the same time as we implement prefixes, add the suffix
`_old' to those symbols that we plan to replace later. E.g.,
`al_set_palette_old()' uses 6-bit palettes, and `al_set_palette()' would
not exist until we implement 8-bit palettes. This would make it easier
to port programs from Allegro 3.* to 5.*, and keep compatibility between
5.0 and 5.*.

> This may or may not become 'Grozilla.}

Sorry for my ignorance, but what exactly is 'Grozilla?

Also, are there more API-breaking changes that we should throw in in
5.2? Things that come to my mind are:
 - Get rid of (some) global variables and states. E.g. `text_mode()'
could be an argument to `textout()' rather than a global variable. (I've
never understood why background and foreground color should be treated
differently in the API.) I don't know if it is worth the effort though.
 - Replace '#' as separator between datafile name and object name, e.g.
by '/' (or does that cause problems in some situation?). The problem
with '#' is that few, if any, of Allegro's file functions work with
filenames that actually contain '#'. Maybe I'm the only person who has
even noticed this though, in which case it probably doesn't matter...

Sven