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 ([email protected], #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
