Hi Bas, does Debian really think it's stable or of any other benefit to stick to outdated libraries for about 3-4 years? And do I have to forget about all new Qt features just because of that? Seriously..I will not.
It's not about that special line of code as it's function is not really relevant. So if it is of help to you I can #ifdef it of course. But sticking to outdated libs for years is beyond being reasonable or conservative. And I doubt other projects limit their development to Debian release cycles. So I will not swallow too many of those #ifdefs. Btw. On my SuSE system the official Qt version is 5.4.2 since a few months. And I expect it to be updated to 5.5 with the next SuSE 42.1. Imho a frequent update and development policy is what Linux is about. If I want to mess around with outdated APIs for an eternity I can use Windows. See commit 68afe765a818fa5ece75955cfe646784dcfd8383. This should restore backward compatibility for now. Oliver Am 30.09.2015 um 12:10 schrieb Bas Couwenberg: > On 2015-09-30 09:38, Oliver Eichler wrote: >> is that really necessary? I thought the benefit of Linux is to get >> updates fast and frequently. I have a certain understanding that it >> takes some time for the latest and greatest to hit the binary >> distributions. So patching a Qt5.5 feature is kind of ok. But Qt5.3 is >> over 1.5 years old. And Qt5.4 roughly a year. >> >> To be honest I hate #ifdef because the code gets harder to read and to >> understand. You can't avoid it completely. Especially for the portable >> stuff. But for transient things like library versions I would like to >> keep it to a bare minimum. Is there no other way? > I'd like to provide QMapShack updates to Debian stable users too, so > they're not forced to compile it themselves and have a newer version > available than 0.6.0. Because of the Qt 5.4 requirement for QMapShack > 1.3.1, I cannot update the backport and have to leave it at 1.3.0. > > It will take about two years for the next Debian stable release to be > available, which will include Qt 5.4 (and possibly newer) and the > QMapShack updates it enables. A strict interpretation of the Basic Rules > for Backports [0] I should remove the QMS 1.3.0 backport because it is > not in testing, 1.3.1 is, this brings QMS users back to the stone ages > version and feature wise so to speak. I won't interpret the backports > rules that strictly, because keeping the backport at 1.3.0 is preferable > over forcing users back to 0.6.0. Backporting security fixes is > complicated by not having the same version in testing, hopefully no > security issues will be found in QMS to keep this a theoretical concern. > > I'm not sure what the Qt 5.4 availability in other distributions is, but > everyone still at 5.3 is stuck with QMS 1.3.0 just like Debian stable > users. > > [0] http://backports.debian.org/Contribute/#index7h3 > > Kind Regards, > > Bas > > ------------------------------------------------------------------------------ > _______________________________________________ > Qlandkartegt-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users ------------------------------------------------------------------------------ _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
