ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Aaron J. Seigo]

On Saturday, June 9, 2012 13:40:29 Andreas K. Huettel wrote:
> Am Samstag 09 Juni 2012, 12:57:16 schrieb Aaron J. Seigo:
> > now, i really don't understand the use of words like stupid and dumb.
> 
> I'll leave the fist fighting to others, and would like to apologize for my
> choice of words.

cool; thanks for that.. this is the KDE i grew to love :)

> I still dont think the decision to freeze master was a good or necessary
> one. It's perfectly reasonable to say "hey let's only do bugfix/minimal
> changes to *any* kdelibs branch for now, even if for everyone's convenience
> we keep the usual branch structure".

iirc, that's what we've done. 4.7.x libs branch was similarly frozen, and then 
we bumped it to 4.8.x ... i assume we'll do the same for 4.9.x. 

personally, i think it is completely unnecessary and that we should all get 
used to it now because it could happen in future that Frameworks are released 
on a different release cycle to applications so that "kdelibs version == 
workspaces version" will get broken. already kdelibs version != apps version 
for many KDE applications, particularly many of the bigger ones like digikam, 
amarok, kdevelop, calligra, etc.

this is analogous to how we have a minimum Qt version for kdelibs and the two 
are not kept in lock-step.

> In the worst case you'll end up with two identical, redundant branches.

which is exactly what caused the current misunderstanding, btw :)

> In the best case a few things (like the mentioned udisks2 support) could
> creep into master, as backport from the frameworks. (Gentoo would like to

rules are there to be broken with wisdom. :)

in the case of a well tested backend that is already in frameworks branch and 
does not touch the public API and which is required by a significant % of our 
OS partners, i can imagine that an exception could be made.

such an exception would require a cogent, clear, calm-headed proposal that 
should cover the following:

* OS targets affected (let's us determine the benefit to work against the cost)
* impact on other OSes (in this case that should be "no impract", but cover 
that so nobody asks in a follow up email :)
* public API impact
* private APi impact
* why it can not be distributed as a separate tarball / repo (e.g. "the API 
that must be implemented is private" or "the backends are not dynamically 
loaded at runtime but built into the library at build time" .. whatever is the 
case here)
* confirmation that it has been implemented in the frameworks branch
* confirmation of who is the maintainer should any bugs arise

*if* the benefit is high and the impact is low, then nobody here is 
unreasonable. we may be strict, but that's different from unreasonable ;)

things that change APIs, that do not leave kdelibs non-useful on large %s of 
user systems, etc. would therefore not meet the likely requirements. and i say 
that as someone who is sitting on patches to kparts (written by Ivan, not me 
:) that i would LOVE to see in kdelibs now rather than later (we use those 
patches in Active images actually :) ... so this is a standard i believe in 
strongly enough to hold my own interests to as well :)

cheers.. and again, thanks for helping bring this back to a productive 
discussion point!

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120609/5f65c6c2/attachment.sig>