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