ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Aaron J. Seigo
aseigo at kde.org
Sat Jun 9 13:30:03 UTC 2012
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/release-team/attachments/20120609/5f65c6c2/attachment.sig>
More information about the release-team
mailing list