migrating old metadata (kdesrc-build action needed)

[Harald Sitter]

On Sun, Nov 3, 2024 at 9:35 PM Ben Cooksley <bcooksley at kde.org> wrote:

> On Mon, 4 Nov 2024, 7:54 am Harald Sitter, <sitter at kde.org> wrote:
>
>> Ahoy
>>
>
> Hi all,
>
>
>>
>> Currently we have two sets of duplicated metadata one in the ksb format
>> and one in yaml. Nico wants to only have one, and I for one agree with
>> this. There are also some broader repo-metadata changes coming, not sure
>> how much they impact kdesrc-build but the lack of input from the
>> kdesrc-build side is concerning at least. So, someone should get involved
>> on those (see the issues/MRs on repo-metadata for details).
>>
>
> I can confirm we're looking to make some changes to the general repository
> metadata files yes - particularly around removing some keys that don't
> quite make sense anymore (like projectpath and repoactive) as needs have
> changed and the metadata needs to evolve accordingly.
>
> My previous plan had been to keep them around for compatibility, however
> ideally we could drop them - so it would be nice if someone (who steps up
> to update kdesrc-build to use the yaml files that serve as configuration
> for kde-builder) could also update kdesrc-build to use the new kind /
> lifecycle keys for the metadata at the same time.
>

Yeah I too was thinking compat is warranted, but realistically we can't
keep adding layers of compat rigging, we'll end up with unmaintainable code
that nobody can reason through. What I think makes most sense is to
deprecate stuff in transitional periods and then throw it away after a set
amount of time. Same goes for kde-builder compat for that matter. That way
we can keep our code maintainable, allow for growth, and not break things
too aggressively.

HS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20241104/e031adca/attachment.htm>