On Saturday 14 February 2015 14:30:17 Matthew Dawson wrote: > On February 14, 2015 04:25:24 PM you wrote: > > But do you have a better solution in mind for this problem? > > I do. As far as I understand the problem, kconf_update creates a > configuration file to record the fact it ran, even though the file was > empty. This solution works as it disables the kde4 scripts, and relies on > the fact that their are now KF5 related scripts to run. Once they start > popping up, the same issue will arise, I believe. > > My idea is to get kconf_update to run more reliably against all > configurations, and to have it not create a practically empty configuration > file to record the fact it ran against a missing file. But I'm not sure how > I want to tackle it, as it seems the only way to do it is to have an index > of the update scripts be built, which I don't want to require unless it is > absolutely necessary. But I have a feeling it is. > > Regardless, it isn't going to make it for 5.7. > > > If the choice is between > > > > 1) a very small number of very recent migration scripts needing an update > > to add Version=5 (as has been done in plasma) > > > > and > > > > 2) all the users trying Plasma 5 losing all their KDE SC 4 settings (at > > least in all apps that ever had any kconf_update script) > > > > ... shouldn't we pick option 1? From a user's point of view it seems much > > less of a problem (and it only affects early adopters, on apps where we > > didn't notice the missing Version field, further reducing the problem > > space). > > > > On the other hand this commit, i.e. option 2, means that for at least > > another month, everyone trying Plasma 5 and KF5-based apps "for real" (not > > just in a test account) will be very disappointed at losing all settings - > > no? > > If its ok to break backwards compatibility at this point, I'm happy to > revert my patch and move on from there. Having a version is a good thing > to have in a file anyways, and requiring it is fine by me. As long as > everybody upgrades now to KF 5.7, and everything is made to run against it, > we shouldn't face too much pain now. It should be mentioned in the > Changelog, and there is a warning printed, so its not an invisible change. > > Since KF 5.7 is already packaged, maybe we should let KConfig 5.7 go out as > is. I'll revert my patch, and see what comes. If someone complains/files a > bug report, I'll put my patch it again for 5.8 (preferably before the > tagging date!). Otherwise we will continue with requiring the version in > the file. Does that sound good to you?
Yep, sounds good. Thanks. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team