search

thorwe / CrossTalk

A Teamspeak 3 plugin that enhances the general audio experience and provides advanced features for commanders.
https://www.myteamspeak.com/addons/9ddfa0b2-25c2-4302-8a43-07f8819af9a9
MIT License
47 stars 12 forks source link

CrossTalk_1_6_3_090501-beta not backwards compatible with TS3.0.16 #28

Closed zsawyer closed 8 years ago

zsawyer commented 8 years ago

Hi,

I have CrossTalk_1_6_3_070301-beta installed. When I started my TS 3.0.16 as usually it notified me about an update of CrossTalk (compiled for 3.0.17). But that does not seem to be backwards compatible with my version. Are you going to make it backwards compatible?

Regards , zs

Error message:

ts3client_win64.exe - Entry Point Not Found

The procedure entry point ??0QSqlError@@QEAA@AEBVQString@@0W4ErrorType@0@0@Z could not be located in the dynamic link library Qt5Sql.dll.

ts3-0-16_crosstalk_1_6_3_09-error

thorwe commented 8 years ago

That's not very attractive, as it's not just compiling against a different target - the source code from 3.0.17 onwards is also going to be different, unless I'd be willing to not use C++11/14 functions. Changes for compatibility with C++11 are the sole changes of the latest beta update, so there's not much of a point for having that in 3.0.16.

All in all, I feel it's more feasible to sort out what's holding you back from 3.0.17 than me starting forks for different TS versions. Did you try if the 3.0.18 beta fixed whatever the problem is with 3.0.17?

Bluscream commented 8 years ago

You should really consider updating to 3.0.18 [Stable] as 3.0.16 is a big security risk to you!

zsawyer commented 8 years ago

@thorwe Thanks. I do understand your reasoning and for this particular release it seems really like a no-go. Are you interested in any future backwards incompatibilities I might spot? Or is this generally of no concern to you?

For my reasons: ACRE usually lags behind on updates for TS3. Since it is one of the main reasons I use TS3 it is my indicator for when to update TS3.

@Bluscream: what is the big security risk you speak of? Nothing in that regard has been mentioned to have been fixed. Do you have any source for your claim? http://forum.teamspeak.com/showthread.php/119239-TeamSpeak-Client-3-0-17-released http://forum.teamspeak.com/showthread.php/120411-TeamSpeak-3-Client-3-0-18-released

thorwe commented 8 years ago

It's not the client per se that's been vulnerable, it's simply been en vogue the last couple of weeks to disguise server welcome messages as "Teamspeak update" notification pointing to some, you guessed it, completely proper download location... The latest client adds some warnings on hyperlinks to external sites.

Backwards compatibility is broken in the following cases: Plugin API update (rare), Msvc update, that will happen again once TS switches to Visual Studio 2015 (or...17, 19, 20, or whatever ;) ) Major Qt Update (extremely rare), usually stuff keeps running, e.g. the client 3.0.18 updating to Qt5.5 is not an issue, the plugin will happily use that one.

Point 2 & 3 are somewhat CrossTalk specific, since I a) use Qt and b) use Qt in a way that I have the same instance than the main program, which enables certain information to flow that'd be less elegant to get otherwise. That's why compiling in a way that I'm independent from the client's msvc + qt version, by bringing my own ones so to speak, would break things. Arma afaik also uses Qt, but I don't know if it's also compiled in that more fragile way I do, or if it's just using it for the UI (then it wouldn't need to do that).

Other than that, there shouldn't be a problem with updates, feel free to report if there're, could be sth. small who knows.

An easy way to test that is by using a second client (temporarily). TeamSpeak actually doesn't really use the registry other than for uninstall routines. Settings are either in TeamSpeak/config order %LOCALAPPDATA/TSClient. Hence, one can simply copy the TS program folder to another location, say c:\TS_Test, update it there and see what happens. Just in case you weren't aware :)

TLDR If it's just some Plugin API update in an irrelevant function, where I just can do another compile and have this done in a couple of minutes, sure. If there's more work involved, splitting code bases and such, odds are against it, after all I'm barely keeping up with maintenance and delivering promised new features as it is and then there're decisions to be made what to spend limited time on.

zsawyer commented 8 years ago
  1. I understand it won't be done for this version.
  2. I will keep mentioning backwards incompatibilities as I spot them since those require individual decisions.