2015-06-09 18:31 GMT+02:00 Christian Mollekopf <[email protected]>: > On Tuesday 09 June 2015 17:43:28 Hrvoje Senjan wrote: >> 2015-06-09 16:58 GMT+02:00 Christian Mollekopf <[email protected]>: >> ... >> >> > 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 > [email protected] > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
