On Tuesday, 20 March 2018 07:20:21 CET Ben Cooksley wrote: > On Tue, Mar 20, 2018 at 10:36 AM, Sandro Knauß <[email protected]> wrote: > > Hey, > > > > On Montag, 19. März 2018 20:26:36 CET Volker Krause wrote: > >> On Monday, 19 March 2018 18:15:49 CET Jonathan Riddell wrote: > >> > On Mon, Mar 19, 2018 at 06:04:51PM +0100, Volker Krause wrote: > >> > > >> > https://community.kde.org/Policies/Application_Lifecycle > >> > > >> > > (1) We do not do "direct-to-frameworks" releases, ie. new modules > >> > > should > >> > > be battle-tested elsewhere before moving to KF5. > >> > > >> > I don't know of that but once in frameworks there's strict ABI > >> > requirements > >> > > >> > so it's usually best to test elsewhere. Self released extragear is > >> > easy > >> > enough. > >> > >> Can Application modules depend on libraries from Extragear releases > >> though? > > > > Why not? Applications can depend on everything external and internal KDE > > including Extragear. > > The only restriction here is that the Extragear component is released > prior to Applications making it's release. > (ie. you shouldn't be dependent on the latest git version)
Ok, then Extragear is at least a theoretical path towards Frameworks, while still being immediately useful for Applications. Still feels a bit weird to be "punished" for thinking ahead by having to do manual releases, compared to looking at Frameworks as an afterthought. > Otherwise there is no limitation on Applications -> Extragear (or > Plasma as the case may be) > > Playground on the other hand is quite different - nothing outside > Playground may depend on something in Playground. > > >> > > (2) We do not do releases from playground, and following that, no > >> > > released > >> > > module can depend on playground modules. > >> > > >> > You can make alpha releases from playground, but not beta and final > >> > > >> > > (3) Module moves have to be avoided where possible, ie. they should > >> > > only > >> > > be done to fix stuff, not as a planned evolution of a module. > >> > > >> > No reason why that should be. Moving from Applications to elsewhere > >> > I'd > >> > avoid just because of the version number lowering which annoys > >> > packagers. > >> > >> Right, which excludes the Application -> Frameworks move which is > >> particularly interesting for a number of framework candidates in KDE PIM. > > > > Jonathan only mention, that he would avoid it because of the version > > number > > lowering. It is not a rocket science to bump the epoch number in > > distribution but still work... And at least in Debian we need to test > > with each move between different release cycle, what has changed, if the > > new version breaks older builds. > > > > For me it is more obvious, that if you release a 0.90 in Extragear f.ex. > > and no changes for 6 months and than a new version in Frameworks, from > > what point the API/ABI is stable. Keep in mind Application releases are > > not connected to the internal state of the product. > > > >> Maybe if possible and doesn't feel forced, there can be a name change/ > > > > improvement that may help? > > > > +1 do not use the KF5 namespace before it enters KF5, therefore you have > > the review process to finalize the lib for frameworks. > > Please note that this can create some significant issues with > backwards compatibility during the transition period (for an > applications to frameworks move for instance), as we found out with > Purpose. As it turns out, CMake does not like creating forwarding > targets, particularly on Windows. > > Therefore you might want to start using the KF5 prefix, and port all > applications to that, a little bit before you enter review for > Frameworks. That's what we did for the KHolidays move a while ago, which AFAIK worked quite well, being a drop-in replacement in all aspects. I might not be seeing the full distro picture there though. It's IMHO worth finding the best path here, as with the KDateTime port completed in PIM, there are a few more former kdepimlibs libs (kcalcore, syndication, kmime, kcontacts, etc) lined up to become part of Frameworks, preferably in the least painful way possible :) Regards, Volker
signature.asc
Description: This is a digitally signed message part.
