Versioning of Frameworks

[Martin Gräßlin]

On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
> On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> > On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
> > <chrigi_1 at fastmail.fm> wrote:
> > 
> > 
> > Hi Christian,
> > I understand your needs, I've seen similar complaints before.
> > 
> > Letting frameworks depend on different versions could make sense, but
> > I also fear it might make it much more complex to maintain quality as
> > a whole. For example, in Plasma we've had problems already because of
> > the fact that we need to make sure different versions are compatible
> > with each other. Also we won't be able to run our CI with every single
> > combination, which also makes it slightly more complex.
> 
> I understand why it may seem more complex, but I don't think it actually
> is.
> Whether we choose to track development process using a version number,
> or whether we choose to track time using that number, what happens in
> the code
> remains the same. The same goes for dependencies; We will always have to
> rely on
> newer features sometimes, and thus bump dependencies.

which means it will in practice be always broken. Real world example:
kwin.git/CMakeLists.txt

set(KF5_MIN_VERSION "5.8.0")

yeah sure, that looks a lot like someone forgot to update the dependency. We 
basically require that developers check for each change:
* which version of a given framework the API call was introduced
* whether that's currently the required dep
* otherwise increase the dep

That's not going to work. We either have CI for that (which we don't and don't 
have the resources for) or we go the secure rout: bump all at once.

As much as I think that in theory you are right and a more fine granulated 
dependency checking would be better, I doubt that this can work in practice 
without proper CI (and of course the CI can only check build deps, not runtime 
behavior changes (e.g. KWin needs a bugfix from KWindowSystem 5.10)).

Cheers
Martin
-------------- 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/20150429/38ba5c47/attachment.sig>