Can we please avoid the term "KDE6". At least my impression is, that we told people quite often about the separate products and that KDE is the community, which is hard to version ;-)

@aacid @heikobecker Can you please add a note to the 22.08 tarball release announcements about the repo/tarball name change? Hm, actually I would have thought there might be some "new/removed" section for each KDE Gear main release, where this would be fitting, but could not find that, did I look at the wrong places? At least I saw such "Added/Removed" section in the KF announcements.

Probably doesn't matter much, but if there is no respin (which seems like a reasonable bet) it could happen even now.

It's quite ad hoc but it seems to work well on an effort-to-reward ratio as I do see people posting these bugfix announcements on social media.

To coincide with the next major version of the release service, on April, 22nd?
https://community.kde.org/Schedules/release_service/21.04_Release_Schedule#Thursday.2C_April_22.2C_2021:_21.04_Release

A few suggestions for notable changes (not entirely confident what to pick, because doing this for the first time):

Search for "Preliminary changelog" in this and you'll get a link to it, with noteworthy changes added as a comment ;)

In D29303#677015, @dfaure wrote:

So this is basically the same as https://phabricator.kde.org/D29136 except that D29136 gives priority to the non-deprecated variable. Any reason against going with D29136 after all?

How do we move this or https://phabricator.kde.org/D29136 forward? @ilic As a maintainer, do you have an opinion?

Maybe worth adding that knotifications also depends on it.

This breaks the lookandfeel-kcm test. I saw this with 5.18.5 but it also fails on build.kde.org for a while, e.g.:

Abandoned in favour of https://phabricator.kde.org/D29136

Fixes the problem I had with marble, which prompted the creation of https://phabricator.kde.org/D29136. Passing the destination as an parameter seems indeed like a better way, so +1 from me.

Where would you see "that the macro already used KDEInstallDirs before"? When it comes to "LOCALE_INSTALL_DIR", that is set to a default is not set when calling the macro. Ideally would be documented though. (my first approach would be to also allow a soft dependency here on KDEInstallDirs, checking whether KDE_INSTALL_LOCALEDIR is defined and picking its value), similar with CMAKE_INSTALL_LOCALEDIR to support GnuInstallDirs automatically).

In D29136#660270, @kossebau wrote:

using kdeinstalldirs variables needs to ensure that KDEInstallDirs has been included before, also introduces ahard dependency on ECM for any users of KI18n. While 99% of apps using KI18n might do this, by design idea of KDE Frameworks KI18n as tier1 should not pull in another dependency, even ECM (so someone using plain cmake & GnuInstallDirs should be still able to use tier1 stuff). This needs some more pondering then...

Added missing parentheses

Yeah, it should've been... /me fetches brown paper bag
Thanks for noticing.

e17a38b179197d9afa303de6e254fbc284c5fa9e did something similar, I suppose this can be closed?

It will (parts of it already have). "to Opt In" is the important part of the sentence. Soon everything will be moved to gitlab, see the thread on kde-devel for more details.