Versioning of Frameworks

[Kevin Funk]

On Wednesday, April 29, 2015 21:43:20 David Faure wrote:
> On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote:
> > Use-case: Potential contributor working on KDevelop:
> > - Has KF5 installed from distro packages
> > - KDevelop/KDevPlatform compiled from Git
> > - There's a bug in ktexteditor (tier 3)
> > - Likes to checkout just ktexteditor, fix the issue, compile, install and
> > use  it
> > 
> > Well, this doesn't work b/c ktexteditor master usually depends on a "too
> > recent version" of its dependencies. So there are two options to still
> > compile  ktexteditor:
> > 
> > a) Compile the complete KF5 set, master branch (exhausting)
> > b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick & dirty way)
> 
> If this contributor was trying to fix a bug in a Qt module, he would
> experience the exact same thing.
> QtAnything 5.5 cannot be compiled with QtBase 5.2.

I'm fairly sure you can; let's say build QtWebChannel 5.6 (dev) against QtBase 
5.4.1. In fact, I just tried again and it worked just fine. QMake did not 
complain.

Sometimes it's interesting to keep the version of the dependencies and just 
play around with the version of the module you're interested into, in order to 
evaluate changes in behavior of your module. By that, you can rule out 
modifications in your *dependencies* did cause these changes in behavior in 
your module.
 
> > I also think this somehow defeats the purpose of the splitting we've done
> > when  you still have to make sure versions of the individual frameworks
> > have to be identical...
> 
> So do you also think that Qt failed with the module split ?
> 
> I disagree. The point (both for Qt and for Frameworks) is that any app can
> decide to use only what they need.
> 
> Having to use up-to-date enough versions of the dependent modules does not
> defeat that purpose.

I can clearly see that lifting the restriction of having up-to-date versions 
of your dependencies creates a "version zoo" as you say. It's untestable b/c 
of the potential combinations and clearly doesn't make the maintainer's job 
easier.

However, I think it could be helpful to be able to build master branch of 
$MODULE against a stable version of its dependencies for *development 
purposes*, which currently isn't possible.

That doesn't mean we should encourage distros to ship a mix of KF5 package 
versions, obviously. They should continue to ship KF5 with identical versions 
for each of the frameworks.

@David: Didn't stress that enough, but huge thanks for taking care of the KF5 
releases!

Cheers

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150430/d0f50927/attachment.sig>