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

[Ben Cooksley]

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)

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.

>
> sandro

Cheers,
Ben

>
>
>
>