Re: [AD] official beta (Re namespace again)

[Bertrand Coconnier <bcoconni@xxxxxxxxxx>]

Since everybody is voting, I will too (see my vote below)

Martijn Versteegh wrote :
> 
> IMHO Peter's original suggestion was by far the best. I don't know how much
> experience you all have with compatability headers which try to #define Rome
> into Paris, but my experience is that you never get it right completely, so
> having a compatability header which keeps floating around forever in
> each new version will be a pain and a burden.
> 
> So I'd say keeping a feature-frozen version 4.0 around for compatability
> will be less work than keeping such a header up-to-date. The 4.0 lib has to be
> minimally maintained to keep working, but as no new projects will be written
> using it (because 5.0+ will have all the exiting new stuff ;-) )
> chances are new problems will not arise much.
> 
> Furthermore such a header will encourage people in using the old api they're
> used to, maybe even for new projects. Which is obviously a Bad Thing.
> 
> IMHO the split in an unprefixed 4.0 and a prefixed 5.0 without any compatability
> baggage is by far the cleanest thing to do. This will also allow us to change
> things like the 8-bit palette & the order of dest&src in draw_sprite etc, which would
> need very complicated macro-magic/#define-crockery to reverse in a compatability header.
> 
> I don't think we need to worry about maintaining 4.0 'for ever' too much either.
> In one or two years all projects which are still maintained will probably have
> migrated to 5.0 , and projects which haven't made the switch to 5.0 are unmaintained
> and probably have rotted more than allegro 4.0 itself, being prevented from working
> by other causes anyway. If someone *really* needs allegro 4.0 at that stage: well
> then you have a volunteer to do the maintaining ;-).
> 
> So I vote for the original proposal:
> 
> 4.0 -> unprefixed
> 5.0 -> prefixed, identical functionality to make switching from 4.0 to 5.0 without side
> effects as easy as possible.
> 5.2 -> truly new stuff added
> 
> While I don't believe in a 100% working translation tool, a 99% working version of
> such a tool would ease the migration from 4.0 to 5.0 a lot, but for this
> to be foolproof it is essential that 4.0 and 5.0 have the same functionality (IMHO).

What else can be said ? ;) I totally agree with Martijn. I vote for this
solution.
May I repeat that I am 100% against Shawn's solution (e.g. keep both API
forever) ? :)

	Bertrand