Versioning of Frameworks

[Christian Mollekopf]

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