On Saturday 14 February 2015 08:48:11 Matthew Dawson wrote: > On February 14, 2015 11:16:42 AM David Faure wrote: > > This is rather a behavior-incompatible change (and another one to revert). > > So, to avoid the packagers killing me for updating 5.7 two days *after* > > the > > supposed public release day (*), I would rather make a 5.7.1 kconfig > > release with this commit in. > > In practice users will only get a few days (at most) with 5.7.0 and broken > > kconf_update behaviour - a runtime bug, it happens. > > > > (*) I forgot to make the tarballs public so I was about to do so right > > now, > > but they surely made their packages public already. > > Ok, sounds good. I didn't see the tarballs/tags, so I wasn't sure if the > release had happened already. I'll try to be better about such things in > the future.
But do you have a better solution in mind for this problem? 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? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
