Versioning of Frameworks

[David Faure]

On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote:
> 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. 

You say at the end of the mail that you are using (or you plan to use only) 6 
frameworks. Having to update 6 frameworks together doesn't seem like a huge 
amount of work to me.

OK, 11, when including the PIM modules which AFAIU aim at becoming frameworks.

> 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.

This would lead to an awful "version zoo".
KIO 5.7 requires KXMLGui 5.5 and KCoreAddons 5.4, but actually KXMLGui 5.5 
requires KCoreAddons 5.5 so overall KCoreAddons 5.5 is required, etc. etc.
Multiply this by 64 frameworks and you have a horrible confusion for everyone 
everywhere.

> 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.

Everything under frameworks/ is released together and with the same version 
number. This includes any PIM-related frameworks.
On the other hand if you mean PIM-related stuff outside of frameworks/, then 
they will have a different release schedule and therefore a different 
versioning scheme I assume.

> * 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.

The whole point of the monthly release cycle is that bugfixes see the light of 
day in the coming month, not 6 months later.
So if we cannot release a new version because no new feature happened (is this 
what you mean?), it would break this concept. Or if you mean releasing but 
with a different version number depending on whether there were only bugfixes 
or also features, then I have to disagree for many reasons, including
- the version zoo mentionned above
- the lack of a clear-cut line between bugfixes and features
- the need for a manual decision in 62 frameworks
- the fact that the workflow for frameworks (master always stable and 
releasable) does not require a distinction between bugfixes and features, like 
the KDE4 workflow required.

> I assume the current versioning is happening so noone has to maintain
> the individual version-numbers

That is one reason, but not the only reason. Making the release dude's life 
(i.e. my life) harder is one thing I'll fight against, but the other reason is 
that a version zoo also makes things harder for everyone else: packagers, 
developers and users.

> 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. 

I'm confused by what you're saying here. If it's not a framework, it's not a 
framework, you can release whichever way you want. But once it's a framework, 
it will be released like everything else, with automatic version number 
increases.

> If it goes well with kimap, I'd then just approach the
> individual maintainers.

There is no point in doing that. They don't release the frameworks.
I do. I release them all.

> * PIM (not yet part of frameworks)
> ** KCalendarCore
> ** KCalendarUtils
> ** KMIME
> ** KIMAP
> ** KContacts
> 
> * Current Frameworks
> ** ECM
> ** KCoreAddons
> ** KConfig
> ** KI18n
> ** KDELibs4Support
> ** KCodecs

Please keep in mind that this is only a very small subset of the overall set 
of frameworks. So if you think that the version zoo from these 11 would be 
manageable, it doesn't mean it would be for the 75 frameworks we'll end up 
with (guesstimate from the current 62 plus a bunch of upcoming pim 
frameworks).

Look at it another way. Does QtNetwork 5.4 say that it requires QtCore 5.2 or 
later ? Does QtSvg 5.4 say that it requires QtGui 5.3 or later ?
No. You install Qt 5.4, you get everything 5.4.

The same happens with frameworks, you install KF 5.9, all the modules are 5.9.
This is not laziness. It's the only way to have something that a human (all 
humans) can wrap their head around, to avoid a complex version matrix with 75 
frameworks each requiring a different version of the 1-to-20 frameworks they 
depend on.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5