--nextPart4559374.LvFx2qVVIh
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; protected-headers="v1"
From: Ingo =?ISO-8859-1?Q?Kl=F6cker?= <kloecker@kde.org>
To: kde-devel@kde.org
Subject: Re: AppStream Metadata with our releases
Date: Tue, 26 Mar 2024 08:35:32 +0100
Message-ID: <4911511.31r3eYUQgx@daneel>
In-Reply-To: <4863078.Dvduau7jar@xps15>
MIME-Version: 1.0

On Montag, 25. M=E4rz 2024 23:23:01 CET Albert Astals Cid wrote:
> El dissabte, 23 de mar=E7 de 2024, a les 21:06:46 (CET), Julius K=FCnzel =
va
> escriure:
> > 22.03.2024 17:22:33 Albert Astals Cid <aacid@kde.org>:
> > > El divendres, 22 de mar=E7 de 2024, a les 0:37:00 (CET), Julius K=FCn=
zel va
> > > escriure:
> > >> - Also it would be convenient to add noteworthy changes to the metad=
ata
> > >> together with the related code change. However at the moment for KDE
> > >> Gear
> > >> the release is usually only added to the metadata a few days before
> > >> tagging. Would it be possible to add the next minor release to the
> > >> release
> > >> branch right after the current one has been released and the next ma=
jor
> > >> release to master ones the upcoming version has been branched?
> > >>=20
> > >> I belive this makes it easier for developers to contribute to the
> > >> release
> > >> meta info and I hope it hence raises motivation to do so.
> > >=20
> > > My pessimistic opinion is that no one is going to add release notes,
> > > we've
> > > tried multiple ways to do it, even just asking people to add a keyword
> > > to
> > > the commit log if that commit log was release news worthy and no one =
did
> > > it past the first few weeks/months.
> >=20
> > Well, that might happen, but we don't know if we don't try... And as I
> > don't see this causing any extra work and (yet) can't see any downsides,
> > it is even worth it if it helps just a single app or developer, no?
>=20
> It is some extra work (not a lot, but some).
>=20
> You're asking for the workflow of creating to be releases to be changed by
> creating the entry in the file earlier, that alone is a bit of work, but =
it
> has several other consequences:
>=20
>  * https://apps.kde.org/okular/ shows releases from the appstream file (i
> think) meaning that the code should learn to ignore releases in the futur=
e.
> Arguably we would need also now, but given the data is added just a few d=
ays
> before the actual release i think users can understand "this release will
> happen soon)" compared to a thing one month in the future

It's not only apps.kde.org. The release (notes) information is also used by=
=20
the scripts preparing meta data for publication in various app stores. The=
=20
Microsoft Store script uses the description of the most recent release foun=
d=20
in the AppStream data for the What's New section. OTOH, the script uses the=
=20
JSONified AppStream data published by apps.kde.org, so that omitting future=
=20
releases in the JSONified AppStream data would also work for Microsoft Stor=
e=20
publications. I'm not sure how the other stores use the release notes.

Regards,
Ingo

--nextPart4559374.LvFx2qVVIh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTbjgIOMowwlCBgvyGxb1mVFkdKugUCZgJ6xAAKCRCxb1mVFkdK
uuITAP0ewFwANDHJ0I3cKIQLG5BOkOwvoK09Q+lYekIBK+t+lwD9HNfLpER1moUi
nwk5lLNUm5c9fBWyDmA3gnSjpG8Bkg8=
=w0FD
-----END PGP SIGNATURE-----

--nextPart4559374.LvFx2qVVIh--