Versioning of Frameworks

[Christian Mollekopf]

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.

It's just, if we don't reflect those changes using version numbers,
because all the numbers
are always the latest and greatest, then we don't know in what state we
are (which library depends on
which version of another library etc.). I don't think it eliminates any
actual problems though (we're only messing
with version numbers after all).

As for combinations, I think it's only normal for upstream to only
maintain the latest and greatest, and do QA for that only.
The regular snapshots that are currently happening can and should
continue to happen, and that's a set that can then
be QA'd etc.

If we did just that, we'd have more meaningful version numbers, and IMO
really wouldn't loose anything.

I of course would then hope to do some release management on the
libraries where it is important enough, and where we
can afford to spend the time for that. On the example of kimap that
would mean that master would be in an always releasable state,
so the frameworks release-process can take snapshots whenever it likes,
and other libraries can depend on whatever version
is currently in master (knowing that the dependency will be released
together with the rest of the frameworks on the next release date). If I
don't manage to get the planned features in for the next release, I
would simply not merge to master, and the framework would stay the same.

If anything that would reduce the combinations that have to be tested,
because some will just stay the same.

> Also we're doing it similarly to how Qt does it anyway. Is it also a
> problem to bump all Qt frameworks when you need another one? Is there
> something that comes easier there that we don't offer? Or is it that
> we just have too many frameworks?

Hmm... Didn't think about that a lot so far.I think in general it would
be valuable for Qt too treat individual libraries separately. I think
it's less of a problem in that case, because the possibility that we
have to update Qt is much lower (I'd typically rather workaround a
problem instead of distributing a patched Qt version, which I guess is a
symptom of the same problem). So Qt is largely not update-able in my
world, which is why I also currently have to maintain compatibility back
to Qt 4.6.2. This of course comes at the cost of maintaining
workarounds, and at an opportunity cost that I end up working
workarounds instead of the core product (Qt).

I don't think we have too many frameworks, what's important for us is to
keep the dependencies to a minimum, and to keep the necessary changes is
those dependencies to a minimum. If we find a bug in version 1.6.3 of
library X (and it really shouldn't matter whether it's a KDE framework
or some other library), then we patch it if feasible and distribute a
fix. If we did our job with that fix
we're not breaking any other uses of that library on the same system an
thus we're good.
If we rely on a new feature of the same library that is in version 1.9,
and we see that all dependencies are still the same, then we can update
to this new version with relatively great confidence and ease, because
we're not touching a whole lot. If updating to 1.9 pulls in a whole tree
of required updates it's just unlikely to happen, and I end up
implementing some obscure workaround  for that.

So I don't think Qt offers anything that helps the problem, it's just
that we interact less with it, and often we just use what's there since
forever anyways and thus we don't care a whole lot about versions.

Cheer,
Christian