Future frameworks releases

[Christian Mollekopf]

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.
* 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