On Sun, 2006-03-05 at 12:54 -0500, Ed Halley wrote: > What with all this talk about merging, I would still like to see the > "official" x.y numbering scheme match that of SDL itself, instead of a > completely different "rewrite two" numbering scheme which bears no > relation to the library it's trying to bind.
I don't agree with this as it is written above. First off, there is the problem that SDL-2.0 has not seen development in 2 years since the initial ideas check-in for it (according to CVS), which would match SDL_perl's version closer, while most of the recent development in 1.2 seems to have been adding ports (OS/2 port seems to be recent) and cleaning up headers, compilation, configuration and compiler support. One might consider SDL to be relatively stable because of this. As such, this leaves little room for innovation or feature adding in SDL_perl that does not match the upstream stuff, or at least no way to designate which versions of SDL_perl have the stuff you need. SDL_perl would need a useless version bump when libsdl is ported to a new platform, something which doesn't affect SDL_perl at all. None of the related SDL libraries (mixer, net, ttf, image) have version numbers that match the libsdl releases. pygame, which also uses libsdl, does not match libsdl's version numbering. I believe it also provides an API which is not exactly a map from the C functions, like SDL_perl does in some cases (I'd like to see things in SDL_perl move away from just effectively exporting C functions in perl style, but that couldn't happen if we are bound by version numbers; fortunately, exporting the C functions almost directly means the upstream documentation still applies). I think that if version numbers are going to mean anything, they should be useful to those who program to the provided APIs, not which dependencies the libraries need. SDL_perl programmers are concerned about the libsdl API, and thus the libsdl version number. Perl script writers who use SDL_perl are concerned with the API provided by SDL_perl. The fact that SDL_perl provides bindings to a C library that uses an independent numbering scheme is, I suppose, an (un)fortunate side effect of having code-reuse and abstraction. But it is a problem that the packager-person or the installer-person has, not the programmer (the fact that often times the packager, installer and programmer are one in the same (at least on non-Windows platforms) is beside the point). I could see some versioning like SDL_perl-<upstream-SDL-version>-<SDL_perl-version> (SDL_perl-1.2.9-2.1.3 or SDL-1.2.9-perl-2.1.3), but this is kind of non-standard, difficult to parse, and might confuse the issue even more. Where does the perl interpreter version get incorporated? Or the version of SDL_ttf? Fact is, SDL_perl is compatible with a whole bunch of releases of libsdl (at least as old as 1.2.6), and a long series of releases of the related sub-libraries. -- Andy <[EMAIL PROTECTED]>
