<div dir="ltr"><div>Rik,</div><div> </div><div>Thank you for making this email and the links. Would a Non-LTS PPA work for those who want to be on the latest and an LTS PPA for organisations?</div></div> <div class="gmail_quote"><div dir="ltr">On Mon, May 21, 2018 at 2:12 AM Rik Mills <<a href="mailto:rikmills@kubuntu.org">rikmills@kubuntu.org</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Our default PPA policy for LTS releases states that [1] "Monthly KDE software release backports are made available through the Kubuntu PPA for as long as supported by the native LTS software stack but no longer than 2 years." For 16.04 LTS we allowed an upgrade of Qt in the backports PPA [2] from 5.5 to 5.6.x, however this was not altogether a radical decision as the Qt 5.6 release was a LTS one, and already being built and maintained by the Ubuntu phone/Qt team in their overlay PPA. For 18.04 LTS, we are already on Qt 5.9 LTS, with more point releases to come, hopefully as SRU updates to the main archive. Now Plasma 5.13 requires Qt => 5.10, so we need to discuss and decide an acceptable course of action, assuming that we wish to provide this and future updates update via a PPA to our users. Realistic options are IMO: (a) Provide updated Qt once again in our backports PPA, but make it quite clear that the level of support, both immediate an ongoing, if users choose to add that and upgrade will be limited by the fact that they are deliberately choosing to move off an LTS supported stack. (b) Keep backports PPA building against Qt 5.9.x, and provide Plasma backports and other software dependant on newer non-LTS Qt in a separate more 'experimental' PPA. (c) Something else? Comment welcome. For simplicity (a) is appealing, and more or less what users seem to be expecting us to do for them. (b) however has some advantages as it would perhaps allow users (say organisational ones) to upgrade to new KDE Applications releases (18.04, 18.08 etc) and others backports, without moving off LTS supported Qt, assuming future Apps are compatible. With Plasma 5.13 as few weeks away [3], and bugfix release to that which we would probably want to wait for before pushing to a not experimental location, not to mention getting Qt built, we have some thinking time. I would also note the decision will be tempered by practical and technical considerations the development team find while doing test builds, and evaluating the quality and stability of the non LTS Qt. Thank you. I look forward to comments. Rik Mills Kubuntu Council Kubuntu Developer [1] <a href="https://community.kde.org/Kubuntu/Policies#Long_Term_Support_.28LTS.29" rel="noreferrer" target="_blank">https://community.kde.org/Kubuntu/Policies#Long_Term_Support_.28LTS.29</a> [2] <a href="https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports" rel="noreferrer" target="_blank">https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports</a> [3] <a href="https://community.kde.org/Schedules/Plasma_5" rel="noreferrer" target="_blank">https://community.kde.org/Schedules/Plasma_5</a> -- Mailing list: <a href="https://launchpad.net/~kubuntu-council" rel="noreferrer" target="_blank">https://launchpad.net/~kubuntu-council</a> Post to : <a href="mailto:kubuntu-council@lists.launchpad.net" target="_blank">kubuntu-council@lists.launchpad.net</a> Unsubscribe : <a href="https://launchpad.net/~kubuntu-council" rel="noreferrer" target="_blank">https://launchpad.net/~kubuntu-council</a> More help : <a href="https://help.launchpad.net/ListHelp" rel="noreferrer" target="_blank">https://help.launchpad.net/ListHelp</a> </blockquote></div>