Future frameworks releases

David Faure faure at kde.org
Thu Jun 18 10:10:29 UTC 2015


On Thursday 18 June 2015 01:03:42 Alexander Potashev wrote:
> Probing question: If I translate one string in kcoreaddons5_qt.po into
> Belarusian language, should we bump and release a new version of
> KCoreAddons because of that?

The question doesn't exactly make sense beceause the po files actually live in 
l10n and get copied into the tarballs (and a git tag) at release time.
So you can't translate directly into kcoreaddons.

However you basically raise the same objection as the one I was going to have 
with "incremented only if there's been commits since the last KF5 release".
A single typo fix triggers a new release then?

Anyway, more importantly, I think Kévin you forgot the problem of the version 
of dependencies. We're going straight into the version hell many of us wanted 
to avoid.

In your suggested scheme, the single number used in kio/CMakeLists.txt 
wouldn't be possible anymore, you'd need to have a different number for each 
dependency, since they might not be at the same numbering at any point in 
time.

find_package(KF5Archive ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5Config ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5CoreAddons ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5DBusAddons ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5I18n ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5Service ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5DocTools ${KF5_DEP_VERSION} REQUIRED)
[....]

If the "single numbering for a release" is just the "2015.07" for marketing,
then it's mostly useless for dependency handling, and we're back to what I 
summarize as "version hell".

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



More information about the release-team mailing list