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@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
