KHolidays in Applications and Frameworks

[Albert Astals Cid]

El divendres, 26 de gener de 2018, a les 11:46:48 CET, Sandro Knauß va 
escriure:
> Hey,
> 
> the question came up, what to do with 17.12.2 and 17.12.3 releases according
> KHoldidays. As you may know KHolidays has moved from KDEPim (Applications)
> to Frameworks and will be released within the next Frameworks release 
> (5.43) too. So for 17.12.2 and 17.12.3 users can get kHolidays from both
> bundles. So what to do?

We release them, we can't drop something in the middle of a stable release.

> I think it is not an big issue shipping the KHolidays in both bundels. As
> frameworks is released from master and Applications has it own branch, we
> only need to make sure, that all bugfixes that are released for
> Applications are merged into master, but this is the default workflow
> anyways. If users already switched to Frameworks  version, should following
> using Frameworks version and not switch back. For users not updated to
> Frameworks version can just follow using the version from Applications.
> 
> So I would argue, that we should not do any special treating for KHolidays
> and just ship two months a nearly the same tarball in both bundles.
> 
> It makes sense to add some lines to the next release announcement of 17.12.2
> and next Frameworks release:
> 
> KHolidays is moved from KDEPim (Applications) to Frameworks. We tried to not
> break your workflow. You have two options. Either you switch to Frameworks
> version and stick to it and do not build and use KHolidays from KDE
> Applications anymore. Or you continue using  KHolidays from KDE
> Applications 17.12.X releases. The versions in Frameworks and Applications
> do only differ in some cleanup and the version number. In theory a smooth
> less switch should be possible without rebuilding depending packages as ABI
> is the same. We the KDEPim team (kde-pim at kde.org, #kontact) also wants to
> move more packages from Applications to Frameworks in future. We are
> interested in your feedback, what can be improved to make it even more
> smoothless switch for the next packages.

Do we really need that? Will users really understand that? Seems a bit too 
much of "technical jargon" to me, and i know what we're talking about :D

Since we think "it'll just work", why bother the user?

Cheers,
  Albert

> 
> sandro