Versioning of Frameworks

Wed Apr 29 09:24:48 UTC 2015

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

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150429/9db7cad1/attachment.sig>