Re: [AD] rest and yield_timeslice

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-07-19 at 08:02 -0700, Chris wrote:
> Elias Pschernig wrote:
> > Old tutorials, like gfoot's Allegro Vivace, don't even works with
> > Allegro 4.0.0 anymore. So that's no argument. We'd still be maintaining
> > the Allegro 1.0 API.
> 
> How doesn't that tutorial work anymore? And why do you think functions 
> like fsqrt, fhypot, etc, are still defined by Allegro despite clashing 
> with libc? Allegro's always prided itself on full API backwards 
> compatibility. If you're going to break the API, you do it once.
> 

Not sure, I seem to remember there's some problems with it, as it was
written for Allegro 3.12.

> >>And break practically every Allegro program in existance?
> > 
> > No. They will compile perfectly fine with Allegro 4.0.x.
> 
> Compile? Maybe.. IIRC, RGB uses signed chars. But still work? Definately 
> not.
> 

4.0.x will keep 0..63, so still work.

>  > But yes, I'm
> > not sure what should be the version for the cleaned up API. All the
> > functions marked as deprecated in 4.1.x are meant to go away eventually,
> > and since they are now deprecated for years, I think it is time to
> > remove them.
> 
> I remember being told that they weren't depricated because they were 
> going to be removed.. they were depricated because they were inferior 
> with no support, past bug fixing.
> 
>  > I remember, when we wanted to prefix all the API some time
> > ago, and had the compromise to make 4.0.x not prefixed, but release a
> > perfixed 4.2.0 with a cleaned up API almost at the same time. It never
> > happed - but I still think it is most important to break compatibility
> > at one point - and 4.2.0 looks like a good point to me.
> 
> 4.2 is way too early. As I said in this email, which is what Shawn has 
> said.. if you're going to break the API, do it once. If you continually 
> break the API, nobody's going to stick with it. 4.2 is way to close for 
> that. We don't have much to change other than removing a few function 
> names.. and I hardly think that's worth an API break.
> 

Not sure. 4.0.0 was released a long time ago. Back then, we thought we'd
have 4.2.x follow quite soon, and also thought Allegro 5 would come
along quickly at the same time. Now, it doesn't look like Allegro will
go anywhere soon, even 4.2.x might well need some time to be released.
So it could be the point where we break compatibility. There will be no
really big changes, just prefixing, and cleaning up the most obvious
shortcomings.

Since everything will be prefixed, there's no real risk of e.g. mixing
up RGB and AL_RGB as well. Someone who wants to compile Allegro 4.0.x
programs will need to use 4.0.x. Someone who wants a maintained lib,
will have to use maintained souce compiling on 4.2.x.

-- 
Elias Pschernig