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

[Sandro Knauß]

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.
 
> > > (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.

sandro