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

[Ben Cooksley]

On Tue, Mar 20, 2018 at 9:02 PM, Volker Krause <vkrause at kde.org> wrote:
> 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.

I'd still consider Applications -> Frameworks fine as a path to be
honest as well.

Saying that something in Applications can't go to Frameworks (because
distributions tooling can't handle the versioning changes) doesn't
make sense.
Given that we've already done it (for KHolidays for instance) I see no
reason why moves like this can't continue to be done.

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

Cheers,
Ben