Future frameworks releases

[Hrvoje Senjan]

2015-06-09 18:31 GMT+02:00 Christian Mollekopf <chrigi_1 at fastmail.fm>:
> On Tuesday 09 June 2015 17:43:28 Hrvoje Senjan wrote:
>> 2015-06-09 16:58 GMT+02:00 Christian Mollekopf <chrigi_1 at fastmail.fm>:
>> ...
>>
>> > Yes, it's a bit more complex, but it's necessary/useful complexity
>> > (because
>> > you gain something from it). It's however still perfectly scriptable.
>>
>> Can you explain why is it necessary and useful and what do we
>> (packagers, or users) gain from it?
>
> Users as in end-users of the applications of course of course shouldn't care
> in either case. Users of the frameworks (i.e. me) benefit from the version
> number in:
> * getting an indicator what has changed (teeny=bugfix, minor=feature,
> major=BIC), and thus whether it's safe to update.

Well, it was decided some time ago, when again packagers wheren't
(too) happy, that
*all* KF5 libs would be feature + bugfix on each release. I know i was
pretty skeptic about that,
but so far things are working OK in this regard, with only a few exceptions
(one runtime break IIRC, and moving stuff from $otherproduct *to*
Frameworks, but that's not a break within KF5).
There where even a few hotfix releases with 5.x.1 version.
BC is guaranteed anyway, so i don't see this as a benefit, especially
benefit that would be worth for 'rules to break'.

> * if you have to backport stuff to older platforms (such as centos 6), it
> helps if you only have to backport the actual requirements, instead of the
> complete dependency subtree.

In my experience, one either pushes an version update (whether .minor
or .patch, depends on a case by case basis), or a backported patch. In
first case then, one would send entire set of updates (e.g. all of KF
5.10). In second case, if you need a patch, it isn't relevant what
version it is anyway.
So as i can see, in both cases version doesn't matter. In theory. In
practice even a bugfix release can break things, so again this isn't
ideal indicator IMO.

> * if you're running a production environment, but need a new feature, risk is
> greatly mitigated if you can update only what you actually need instead of the
> complete dependency subtree.

Hm, i'd say 0.01% of users cherry-pick which updates they will
install. It's all or nothing in almost all cases.

> So for me as a maintainer I loose an important tool, and for me as a user the
> frameworks proposition becomes a lot less interesting because I potentially
> end up having to maintain special branches to solve my needs as a user.
>
>> Size of the libKF5IMAP5 rpm is 172kb(+375 KB for devel package).
>> IMO users wouldn't object installing 172kb more monthly at the sake of
>> consistency
>> (they are already confused enough by KF5/Plasma/Apps + kdelibs4-based
>> libs/desktop/apps splits and versionings)
>
...
> Then I can almost just as well ignore the version alltogether
> if my sole purpose is to get the latest and greatest.

I think that's correct for people that build from git anyway.
Distro users, and self-builders might only get confused by different
version numbers (e.g. 5.22.0 vs 2.3.5).
(Where is the source? Why is this package not up to date!!? I have 55
'KDE5' packages with version 5.22.0, but this one is still at 2.3.5.0)

>> I understand that you as a maintainer would like to have the right to
>> determine your version numbers, but i don't understand then why is it
>> necessary for that lib to be a part of KF5.
>
> Because KF5, for me, should be:
> * an inclusive umbrella for libraries that are written in qt and that come
> with a set of given guarantees (licensing, BIC, always releasable master,
> ....)
> * a shared release infrastructure, which helps both maintainers and packagers
>
> All in all, if you do Qt development and you're looking for a library that
> does something that is not available directly as part of Qt, Frameworks should
> be the go-to place to look for it. That only works if the rules are not too
> restrictive.

Fair enough. That are good enough reasons ;-) But i am still not
convinced that deviating
from rest of the flock is worth the complications are confusions.

Anyhow, to answer again the original question, yes, i guess i could
work with such change, but if it would be a yes/no voting, i'd vote
against it.


Cheers,
Hrvoje
> Cheers,
> Christian
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team