The case for a kdelibs 4.8

[Kevin Kofler]

Markus Slopianka wrote:

> On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote:
> 
>> 2. It will be confusing to our users, and even to some packagers, to have
>> a KDE SC 4.8 on kdelibs 4.7.
> 
> Since almost exactly 2 years we (esp. the promo team) are communicating
> that Platform/Frameworks, Applications and Workspaces are three separate
> products that just happen to be shipped on the same date.

But now you're changing exactly that last part, or at least what will be 
released will no longer have a common and consistent version number.

And in any case, even if this particular argument doesn't convince you, that 
does not invalidate all the other reasons why there should be a kdelibs 4.8.

> One of the reasons why the rebranding still didn't get to everybody is
> that some distributions (mostly Fedora!) still spread the wrong message
> about some “KDE 4.7” to its users. (see eg.
> https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging )

This is not a page targeted at our users at all, it's an internal KDE SIG 
TODO list. We sometimes use shorthand when we discuss things, it is obvious 
to us that what's really meant here is the KDE SC. But I changed it to "KDE 
SC 4.7 Packaging" to make you happy.

And no, we cannot use a more specific term than "KDE SC" here, because this 
is really about packaging all the stuff that happens to be shipped on the 
same date, with a 4.7.n version number, by the KDE Project. The modules are 
released together, so they get packaged together.

> Users of other distributions do not have such problems

Wait and see the chaos that will come up when users open their Help/About in 
Konqueror and it tells them that they're using "Konqueror 4.8.0 under KDE 
4.7.6". (And yes, it still says only "KDE" in 4.6.5, I haven't checked 4.7 
or 4.8 for whether that's fixed there.)

> and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing
> to most users.

Actually, that was (and still is) quite confusing to many users. Look at the 
mailing lists and forums.

I think this was a mistake that shouldn't be repeated. What should have been 
happened when the Akonadi stuff was found not ready would have been a:
svn rm branches/KDE/4.5/kdepim
svn cp branches/KDE/4.4/kdepim branches/KDE/4.5/kdepim
(and likewise for kdepim-runtime. And yes, SVN was still used at that time), 
i.e. mass-revert the unfinished stuff and do 4.5 releases of what works. 
(But the updated KAddressBook from 4.5 should have been used. The 4.4 one 
was already Akonadi-based and unfinished, and we ended up stuck with that 
temporary solution for over a year. It was a mistake to put that into 4.4 in 
the first place, but with that done, it should have been updated. 
Renumbering the releases to 4.5 instead of continuing with 4.4.x would have 
allowed inserting such a new feature.)

>> The rule so far has always been that the kdelibs
>> version must be the same as the KDE SC version.
> 
> There is no rule – at most a common practise

A "common practice" which had been enforced by minimum required kdelibs 
versions in CMakeLists.txt.

> and that was broken as well after Fedora 15 has packages for SC 4.7 with
> Kontact 4.4.

Fedora 15 actually has KDE SC 4.6.x, not 4.7.

The upcoming Fedora 16 has KDE SC 4.7.x including kdepim 4.7.x, so the 
version numbers are finally consistent again.

>> Changing this will also break all our Fedora KDE SC specfiles
> 
> Then fix your specfiles. AFAIK Fedora is also the last big distribution
> that still has monolithic packages like kdemultimedia, kdenetwork, and so
> on. Take the opportunity to fix that as well.

If you had actually read that KDE47Packaging page you linked to and not just 
the title, you'd know that we're actually shipping some modules split in the 
upcoming Fedora 16. Not only are the modules released as split tarballs now 
all also packaged in split form, but we also split e.g. kdeutils into 
subpackages.

>> The main reason that
>> was given for dropping kdelibs 4.8 is that this means one less branch to
>> worry about for the people working on kdelibs, but the people who'd work
>> on 4.8 and 5.0 are NOT the same people!
> 
> Do you hereby declare that Red Hat will provide resources to create KDE
> Platform 4.8 and an cherrypick useful developments from the frameworks
> branch to Platform 4.8?

I cannot declare that because I don't work for Red Hat (let alone in some 
management position). I'm just a community packager for Fedora. Ask Red Hat 
directly.

        Kevin Kofler