Multi-version Compatibility Possible?

Hi,

I want to suggest the possibility of having multiple versions of SDL installed at the same time, much the same way GTK+ and GTK+ 2.0 can be. This is in consideration of the fact that installing SDL 2.0 will break compatibility with SDL 1.0-dependent programs :frowning: . Since SDL 2.0 does not have reverse compatibility with prior versions, updating programs to SDL 2.0 is mandatory asap. Sadly, most open-source development does not usually develop at a mile a minute … more like the rate glaciers move, no offense intended :? . In essence, SDL 1.0 programs will see a sudden drop in support from communities until the programs are wholly ported to SDL 2.0 … which, in at least some cases, will be just long enough for those projects to be abandoned. I fully understand that progressing to new versions is necessary to advance software technology and capabilities, but transition time is a key factor.

I know some programs offer reverse-compatibility for at least one version difference, if not more, but it may cause messes in code, and confusion about what parts should be used and what parts are due to be removed, if it’s not well organized and documented.

In light of the lack of backwards-compatibility, I suggest having multiple versions of SDL installed at the same time. This will at least leave an ample and smooth transition period between versions.

Please take this possibility into consideration, if not for SDL 2.0, perhaps then for future versions. If you agree or disagree, or have alternatives for this, please state so and explain. [Arrow]

Thank you for any consideration. [Wink] :smiley:

I don’t think you have even tried to install both versions at the
same time otherwise you would have seen that it already just works.On 12/12/13 7:05 PM, MajorLunaC wrote:

Hi,

I want to suggest the possibility of having multiple versions of SDL
installed at the same time, much the same way GTK+ and GTK+ 2.0 can be.
This is in consideration of the fact that installing SDL 2.0 will break
compatibility with SDL 1.0-dependent programs Sad . Since SDL 2.0 does
not have reverse compatibility with prior versions, updating programs to
SDL 2.0 is mandatory asap. Sadly, most open-source development does not
usually develop at a mile a minute … more like the rate glaciers move,
no offense intended Confused . In essence, SDL 1.0 programs will see a
sudden drop in support from communities until the programs are wholly
ported to SDL 2.0 … which, in at least some cases, will be just long
enough for those projects to be abandoned. I fully understand that
progressing to new versions is necessary to advance software technology
and capabilities, but transition time is a key factor.

I know some programs offer reverse-compatibility for at least one
version difference, if not more, but it may cause messes in code, and
confusion about what parts should be used and what parts are due to be
removed, if it’s not well organized and documented.

In light of the lack of backwards-compatibility, I suggest having
multiple versions of SDL installed at the same time. This will at least
leave an ample and smooth transition period between versions.

Please take this possibility into consideration, if not for SDL 2.0,
perhaps then for future versions. If you agree or disagree, or have
alternatives for this, please state so and explain. Arrow

Thank you for any consideration. Wink Very Happy


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Did you try it and had an issue? I did it before and it was OK. The surface
is different between versions but otherwise it seemed fine.On Dec 13, 2013 12:41 AM, “MajorLunaC” wrote:

Hi,

I want to suggest the possibility of having multiple versions of SDL
installed at the same time, much the same way GTK+ and GTK+ 2.0 can be.
This is in consideration of the fact that installing SDL 2.0 will break
compatibility with SDL 1.0-dependent programs [image: Sad] . Since SDL
2.0 does not have reverse compatibility with prior versions, updating
programs to SDL 2.0 is mandatory asap. Sadly, most open-source development
does not usually develop at a mile a minute … more like the rate glaciers
move, no offense intended [image: Confused] . In essence, SDL 1.0
programs will see a sudden drop in support from communities until the
programs are wholly ported to SDL 2.0 … which, in at least some cases,
will be just long enough for those projects to be abandoned. I fully
understand that progressing to new versions is necessary to advance
software technology and capabilities, but transition time is a key factor.

I know some programs offer reverse-compatibility for at least one version
difference, if not more, but it may cause messes in code, and confusion
about what parts should be used and what parts are due to be removed, if
it’s not well organized and documented.

In light of the lack of backwards-compatibility, I suggest having multiple
versions of SDL installed at the same time. This will at least leave an
ample and smooth transition period between versions.

Please take this possibility into consideration, if not for SDL 2.0,
perhaps then for future versions. If you agree or disagree, or have
alternatives for this, please state so and explain. [image: Arrow]

Thank you for any consideration. [image: Wink] [image: Very Happy]


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In light of the lack of backwards-compatibility, I suggest having
multiple versions of SDL installed at the same time. This will at least
leave an ample and smooth transition period between versions.

They can already coexist. SDL 2.0 and 1.2 can live together on a system,
and developers can target either they like.

This wasn’t true for SDL 1.3, but we fixed it.

–ryan.