Re: [AD] to prefix or not to prefix (part 2)

[Peter Wang <tjaden@xxxxxxxxxx>]

On 28 Oct 2001, Laurence Withers <lwithers@xxxxxxxxxx> wrote:
> In reply to Peter Wang <tjaden@xxxxxxxxxx>:
> >I'm sick of old code rotting.  If 4.0 is released with prefixes,
> >either I need to update my old code, or use an old WIP. 
> 
> Or use the compatibility header file, which I am confident will work.

Forgive me if I am skeptical (and I am :-)  If a compatibility header
turns out to be extremely good, _then_ we could kill off the 4.0
branch.  We might still want to maintain it, for ABI compatibility.



On 28 Oct 2001, Sven Sandberg <svsa1977@xxxxxxxxxx> wrote:
> > * 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 ?

I can't think of anything better.

> > * 5.2: The prefixed API, with new features.  Once people are used to
> >         the new API, we would release this.
...
> 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)? 

That was the compromise.  I had imagined 5.0 to be the prefixed-and-
cleaned-up API, but Bertrand was concerned that 5.0 would be delayed
for years (I'm sure it would have been) and that the prefixed API
would never come.

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

That's one way.

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

I like this second approach very much, but I like Laurence's naming
better, i.e. al_set_palette6 instead of al_set_palette_old.  Or maybe
al_set_palette_6.  Anyway, it's a good idea.

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

(Not sure either.)

- *blit* and *sprite* are on my list.  The ordering of the source and
destination takes a while to learn, and is kinda ugly.  Unlearning
might be even harder...


On 28 Oct 2001, Bob <ohannessian@xxxxxxxxxx> wrote:
> 
> I agree with the idea of the proposal , however, I don't agree with the 
> version numbering. Major version numbers should be reserved for major 
> changes (ex: 3.0 vs 4.0), and not for a slight rename of the API.
> 
> I would rahter see it this way:
>   - 3.9.xx (3.5?) Current WIP (WIP40) + bug fixes
>   - 4.0           Prefixed API
>   - 5.0           Completely new API, with 8 it palettes, combined BITMAP,
>                   RLE_SRPITE, possible merge of AllegroGL, more object
>                   oriented, and so on.

But this would mean cross-platform support gets shoved in 3.x!
If you keep in mind that the biggest change between 2.2 and 3.0 was
truecolour support, then the work of the last few years definitely
deserves to be 4.0, even without prefixing.


Based on the input so far (thanks everyone), this is a follow up
proposal.  Let's hope I'm not pushing my luck :-)

------------------------------------------------------------
	
* 4.0: as before

* 5.0: prefixed (and suffixed) API.  This is more of a stepping stone
	than before.  We'll need to decide what to break in 5.2, so
	the release might be pushed a little further back, until
	everyone is happy (well, *almost* everyone, else it'll be
	another four years).  The CVS tree will still be open early.

* 5.2: phase two of the new API: adding 8-bit palette, etc.

  And then one of:

  * 5.2a: 5.0 compatibility maintained, 5.0 killed.
        + less work for maintainers
        + more work for users (only one major API break)
        - more baggage

  * 5.2b: 5.0 compatibility broken, 5.0 possibly maintained.
        - more work for maintainers (if 5.0 kept)
        - more work for users (two major API breaks)
        + less baggage

------------------------------------------------------------

It's not necessary to decide between 5.2a and 5.2b yet, and we can
change our minds right up until 5.2 release time.  Indeed, the choice
will depend on how long 5.0 is around, and maybe even *gasp* a users'
vote :-)