[kde-release-team] Re: New module: KPkPass

[Volker Krause]

On Tuesday, 20 March 2018 07:20:21 CET Ben Cooksley wrote:
> On Tue, Mar 20, 2018 at 10:36 AM, Sandro Knauß <sknauss at kde.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180320/8e498e39/attachment.sig>