Plan to transition to KDE Frameworks
faure at kde.org
Wed Aug 10 13:39:49 BST 2011
On Tuesday 09 August 2011 19:26:17 Scott Kitterman wrote:
> On Tuesday, August 09, 2011 07:05:53 PM David Faure wrote:
> > On Monday 08 August 2011 00:42:50 Scott Kitterman wrote:
> > > On Saturday, August 06, 2011 09:32:02 AM David Faure wrote:
> > > ..
> > >
> > > > The next step is to backport the few bits of new api that went into
> > > > master and that application developers started using, into the 4.7
> > > > branch of kdelibs. I'll work on that, but help is welcome too.
> > >
> > > ...
> > >
> > > This plan seems to be contrary to the KDE Point Release Policy . At
> > > this point I don't see an easy way out, but it would be good if a cutoff
> > > point for these additional API changes in 4.7 could be set (perhaps no
> > > later than 4.7.1's release).
> > >  http://techbase.kde.org/Policies/Minor_Point_Release_Policy
> > Under some conditions, the policy allows new API in a stable branch.
> > We decided that these conditions were met :-)
> > (IIRC there were only three, and they were rather minor and safe; a
> > KUrl::List constructor, a new exported method, a new signal)
> Just to be clear then ... No further API changes are planned for
> incorporation in the 4.7 branch? From a distro perspective it matters to me
> that the API be stable after our release (which will be with 4.7.1 or 4.7.2
> depending on when they are released), so as long as it's those and no
> others I'm perfectly happy.
No further plans for new API right now, but as the policy says, it can always
happen, if it's necessary for a bugfix.
But surely if a distro provides an update to someapp-4.7.3 it can also provide
an update to kdelibs-4.7.3, via dependencies.
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
More information about the kde-core-devel