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. * 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. * 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. 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) I don't think simply ignoring the versions and timestsamping everything makes anything easier. Then I can almost just as well ignore the version alltogether if my sole purpose is to get the latest and greatest. > > 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. Cheers, Christian _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
