On 26 April 2014 15:50, Albert Astals Cid <aa...@kde.org> wrote: > In my opinion we should not release KDE Applications 4.14 LTS and we should > not release KDE Applications 4.15 either. > > We should just release KDE Applications 2014.12, that is, the set of KDE > Applications that was released on December 2014. > > In that set of applications we can release both applications based in kdelibs4 > and in KF5. > > There is nothing that prevents us doing that since now almost every other > application is in it's own repository (kdepim* and kdeplasma-addongs being the > only exceptions where it should be an repo-decision and not app-decision) > > By letting applications choose when they want to change from shipping a > kdelibs4 based version to shipping a KF5 based version we ensure we do a > smooth as possible transition instead of ending with "it compiles ship-it" > stuff in KF5 versions. > > Of course this may mean some people decide not to never do a KF5 port since > they prefer to keep adding features instead in investing time in porting to a > more future-proof foundation like KF5 is, so we should have a limit, let's say > "KDE Applications 2015.12" as the last "KDE Applications" release in which we > would accept kdelibs4-based applications.
I agree with Albert. In fact, this was a "design feature" of the whole split-up-SC effort. With 4.0 *everything* had to be changed at the same time which led to long delays and lots of semi-broken code at release. With split repos, phased Frameworks / Workspace / Apps initial releases, and coinstallability, we don't need all apps to be ready to port and release at the same time: you have a KDE Applications release containing kdelibs4 and KF5 apps, not a KDE 5 SC release. Some app maintainers will have kdelibs4 features in progress they want to finish and release first, especially with GSoC in progess (we don't want to demotivate students), others will have maintainers ready to go the day KF5 is released. That's fine, we can accommodate that like Albert says, kdelibs4 based apps will run just fine on Plasma Next, and KF5 apps will run fine under Plasma Previous. So, no such thing as a KDE 4.14 LTS or 4.15, just KDE Applications 4.14 with bugfix releases as normal up to 4.14.6, followed by KDE Applications Release 2014.12 which will mix Qt4 and KF5 apps, followed by releases every 4-6 months. Apps should aim to have every release during the transition phase be a "stable" release aimed at end users. If that means an app tags a bug-fix-only 4.x based version for inclusion the next release cycle then that's fine. Some potential issues: Version numbers could be tricky (version number != release cycle number, even in KDE4 SC we have apps that don't have the numbers the same). The apps still based on kdelibs4 should probably use a 4.x version number, probably 4.15 and 4.16, and the KF5 based apps probably 5.x, but I guess this is still an open issue. Some modules may need to coordinate a common release cycle for the switch due to shared libraries and functionality (pim and maybe games being the obvious), but branching allows individual apps to press on with KF5 work while other apps finish features. [I expect PIM may skip a couple of release cycles anyway.] Essential base apps closely tied to the Workspace might need to offer their own LTS releases tied to the Workspace LTS release cycles (e.g. will the NM applet 5 or Dolphin 5 perform perfectly under Plasma Previous?). The switch from KLocale to QLocale may cause a little confusion and inconsistencies when mixing and matching Workspace and Frameworks, but only for people who've customised their locale settings, most people use the default locale so won't notice anything. Frameworks is talking about only supporting the Porting Aids (kdelibs4support, etc) for 3 release cycles, should this be defined as 3 Application release cycles, i.e. 12-18 months? Cheers! John. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
