Versioning of Frameworks

[Jeremy Whiting]

Christian,

David isn't the only one with these thoughts. I agree with everything
he said, and was thinking about the dependency zoo also, but couldn't
form the words until I read what he wrote. That's exactly what I was
thinking. It would be like the old rpm dependency hell from early
linux days all over again, but within our community only.

BR,
Jeremy

On Wed, Apr 29, 2015 at 12:34 PM, David Faure <faure at kde.org> wrote:
> 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
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel