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

[Bertrand Coconnier <bcoconni@xxxxxxxxxx>]

> Shawn Hargreaves wrote :
> 
> It's not really any of my business any more, but I have to say that
> keeping two copies of the lib around (one prefixed and the other not)
> seems ugly to me: it's a doubling of the amount of code out there in
> use and needing to be maintained, and will always be an ongoing task
> rather than something that can just be solved once and then forgotten
> about.

That's why the non-prefixed library will be "feature frozen" forever. 
That way maintaining work will be reduced to bug fixes. New features
will *only* be added to the prefixed library.

> 
> My vote would be for a single codebase that implements both old and
> new API's, and can be compiled for either (but would compile into a
> different lib depending which is selected, just using the function
> macros to mangle things differently). That gives 100% compatibility on
> all platforms without needing any particularly weird tricks, and
> extends well into the future (people can choose either API, but still
> be able to access new functionality as it is all the same codebase).

What is the worse thing ? Maintain two APIs (and *try* to keep them
compatible) or maintain the two libraries the way Peter suggested (e.g.
fully maintain the prefixed one and just bugfix the old one) ?

BTW you suggest that Allegro would compile into a different library
depending on what API the user choose. It looks very much like we would
need to *fully* maintain two *different* libraries. Which is even worse
than what has been suggested so far. Anyway I doubt that a library can
be accessed by two different API without any "weird tricks" unless the
new API functions are just wrappers of the old API ones or vice versa.

And what is the purpose of the new API if we keep the old one 100%
compatible ? As Martijn Versteegh said "(this) will encourage people in
using the old API they are used to, maybe even for new projects".
Moreover the new API is a real opportunity to get rid of some
"weaknesses" of the old API (some people wish to get rid of text_mode(),
to change the "src" and "dest" order or to rewrite the set_gfx_mode
function...). Although some of those changes may be portable to the old
API some may not.

> 
> Second to that, a compatibility header for functions with linker
> fixups for variables seems like a reasonable workaround, although not
> so robust as the lib actually being rebuilt using either set of names.

I can barely imagine how the library will look like with some #ifdef
ALLEGRO_USE_OLD_API everywhere. This seems ugly to me. Anyway, some
functions of the library internally calls some others. So how those
internal calls should be managed ? Should we use the old API names or
the new API ones ? And what if some functions of the new API do not use
the same arguments order than the old API ? Should we #ifdef each
internal call ? What a nightmare !

> 
> If you're going to freeze a version of the old API I reckon it should
> be just that: freeze it and abandon it, tell people to switch API if
> they want something that is being actively maintained. Otherwise you
> will have a nightmare doing support for multiple versions way off into
> the future. It's a safe bet that 90% of bug reports would never bother
> to mention what version they were using,

I disagree with that point : so far on the [AL] list, many bug reports
already do not mention which version they use. But ~100% people have
kindly answered to the now famous question "What WIP version are you
using ?".

> and it's hard to always
> insist people use the most recent if there is such an important reason
> to go on using and old one! And could be confusing for users if there are multiple 'current' versions on > the website, with different reasons to download either.

Why do you want to insist since both libraries are not intended to serve
the same goal ? 4.0 will be released because its purpose has ever been
to be a (improved) multi-platform version of 3.12.
5.0 is a new start in the library history : new API, new
functionnalities and (maybe) a new design but it will hopefully keep
almost the same code :)

Think to the Linux kernels. Even if 2.4.x is out since several months
some patches are still being applied to the 2.2.x series and nobody
seems to get confused nor to complain.

	Bertrand.