Versioning of Frameworks

[Aleix Pol]

On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
<chrigi_1 at fastmail.fm> wrote:
> Hey,
>
> For the Kolab Groupware Server we use some KDE libraries on the server.
> Servers being what they are, the libraries we require are often not
> available by default because the systems are too old, and we end-up
> backporting what we need. To make this feasible in pre-framework times I
> had to create a copy-paste monster that contained all the libraries we
> required, and stripped everything we didn't, to keep the dependency tree
> at a manageable level (so we don't end up updating some 100+ packages).
>
> Now with frameworks, we are finally in the position to get rid of this,
> but as far as I understand, at least some frameworks are in version-lock
> with each other, which seems to defeat at least parts of the benefits.
> Our dependency tree is now indeed reduced, but if we want to update a
> single library, we are forced to update all libraries, due to the
> version-lock caused by periodic bumping of dependencies. This comes at
> significant cost if we have to backport all packages.
>
> Ideally framework-libraries should IMO be versioned as any other library
> that I know of, which is bumping numbers as changes happen. Similarly,
> requirements are bumped as the requirements increase, making it entirely
> possible that some low-level libraries can remain the same while others
> are updated. My favorite versioning scheme is the one explained here [0]
> (major.minor.teeny with minor for features, and teeny for bugfixes),
> which is almost what we do, since we already use the major
> version-number to indicate API incompatibilities. But currently the
> versions are just used to time-stamp the releases.
>
> I think our requirements can be split into two parts:
> * No automatic version-bumping of dependencies: This harms us the most
> because it forces us to update everything when updating something. It's
> not a problem in Tier1 frameworks, but I've seen some doing it (khtml),
> so I hope it's not a policy and we can do it differently in PIM.
> * A version number that follows changes and not time: As I understand
> version numbers are currently bumped periodically because we anyways
> lack the manpower for release-management, and since changes usually
> happen, the version is just periodically bumped before each release.
> This seems to prevent release-management to happen though, where the
> version number is a vital tool for planning what ends up in what
> version. So my question would be whether we could move certain
> frameworks from that time-boxing model to a feature-boxing model,
> allowing the releases to be somewhat planned.
>
> I assume the current versioning is happening so noone has to maintain
> the individual version-numbers, so the question becomes whether it would
> break anything moving partially away from that.
>
> Initially I'd like to stop the automatic dependency bumping, the rest
> can IMO wait some more, that's something that can be solved on the PIM
> side, but I need to know if there are policies regarding that, or if
> some frameworks just choose to do that out of laziness (aka lack of
> manpower).
> The release-management I'd try first on kimap, which is not yet a
> framework, and where I'm maintainer, so my question would be whether you
> somehow rely on all frameworks have the same version, and how we could
> fix that. If it goes well with kimap, I'd then just approach the
> individual maintainers.
>
> It's of course quite possible that I don't understand the requirements
> of others, so I'm interested to hear about that as well =)
>
> Cheers,
> Christian
>
> [0] http://semver.org/
>
> Our dependency tree is roughly (it's currently larger, but we should be
> able to get it down to that):
>
> * PIM (not yet part of frameworks)
> ** KCalendarCore
> ** KCalendarUtils
> ** KMIME
> ** KIMAP
> ** KContacts
>
> * Current Frameworks
> ** ECM
> ** KCoreAddons
> ** KConfig
> ** KI18n
> ** KDELibs4Support
> ** KCodecs
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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.

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?

Aleix