On Tuesday, April 28, 2015 12:17:00 Christian Mollekopf 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.
Just to give my +1 I also think this is a big issue. Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a "too recent version" of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick & dirty way) I also think this somehow defeats the purpose of the splitting we've done when you still have to make sure versions of the individual frameworks have to be identical... Greets > * 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 -- Kevin Funk | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel