[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [kde-community] KDE applications 4.14 LTS or 4.15?
From:       Christoph Feck <christoph () maxiom ! de>
Date:       2014-04-26 9:57:24
Message-ID: 201404261157.24957.christoph () maxiom ! de
[Download RAW message or body]

On Saturday 26 April 2014 10:58:46 Andreas Cord-Landwehr wrote:
> On Saturday 26 April 2014 05:28:18 Inge Wallin wrote:
> > But mostly I think that an LTS release should be about stability.
> > This is not something you get immediately after you port to a
> > new framework and a new toolkit at the same time.
> > 
> > I think we should do a 4.15 and at the same time do as much work
> > as possible to port over to Qt5/KF5. But to think that the
> > result of that effort is worthy of a LTS release is to fool
> > ourselves.
> 
> Hi, I do not think that porting to KF5/Qt5 does block a LTS in any
> way, since porting to KF5/Qt5 is a task that has to be done in
> parallel to the Qt4 development branches. So any (possibly)
> disruptive changes coming from the KF5 port do not effect the Qt4
> version, i.e. the 4.14 release.
> 
> IMHO the advantage by having a LTS release, and this is the main
> reason I am in favor of this idea, is to softly poke ourselves to
> start porting to KF5 soon.

Exactly. We may have developers who are not (yet) fond of the KF5 
idea, and would like to continue adding features to their KDE4 
applications. We can help them getting started by providing the 
initial frameworks branch with CMake porting.

By communicating to our users that 4.14 will be an LTS release, we 
actually explain to them that our power is needed to port to KF5. We 
could make exceptions regarding string additions. For example, the 
Baloo integration in Dolphin is quite young, and if a feature makes 
sense to be added to the LTS release, it should not be blocked. No 
need to call it 4.15, though, because the number of new features 
should be minimal, not worth calling it a "new release".

> [...] The reason behind is that the KF5/Qt5 porting creates
> quite disruptive changes (QtQuick1 to QtQuick2; port away from
> QGraphicsScene). Thus any new feature merges from the Qt4 
branches
> are very painfull.

Note that Qt5 includes both QtQuick1 as well as QGraphicsScene. In 
other words, an initial KF5 port should not need disruptive changes.

Please do not rush to remove all Qt4/KDE4Support code, because that 
may cause breakage that could lead to bad publicity. Like we did with 
removing dependency on Qt3Support, that can come slowly and gradually 
in the coming years.

Christoph Feck (kdepepo)
KDE Quality Team

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]