Re: Versioning of Knights and other KDE games

El dilluns, 14 d=E2=80=99octubre del 2024, a les 10:05:23 (CEST), Alexander=
 Semke va=20
escriure:
> Am 13.10.24 um 22:09 schrieb Albert Astals Cid:
> > El diumenge, 13 d=E2=80=99octubre del 2024, a les 18:26:58 (CEST), Alex=
ander Semke
> > va>=20
> > escriure:
> >> Hi all,
> >>=20
> >> Knights is using its own versioning schema, current version is 2.6. The
> >> name of the package in openSUSE has 24.08.2 in it which implicates it's
> >> being part of KDE Gears. The situation is similar for other KDE games.
> >> I'm not sure how this is handled in other linux distributions, though.
> >>=20
> >> Is there a reason why KDE games are not part of KDE Gears and how is t=
he
> >> release process handled for KDE games?
> >=20
> > knights is part of KDE Gear, what makes you say it isn't?
>=20
> I _assumed_ this is not the case because of the different versions used
> by the different games that are not consistent with the versioning used
> for other applications under the Gear umbrella. I see the packages for
> KDE games now listed on the download page for Gears. For a user, seeing
> the version 0.9.24082 for KMahjong or the version 2.6.241170 for Knights
> in the about-dialog is not obvious these applications are part of the
> same "bundle", are following the same release schedule and the last
> release is 24.08 - why do I see 24.08.2 for Dolphin but not for KMahjong
> which are both part of the same release?

KDE Gear is mostly a "marketing term" we release things at the same time=20
because it's convenient, I am persinally not convinced the user cares if=20
Dolphin and KMahjong have different actual versions.

>=20
> >> Who/what is defining when the
> >> next release is done and the code can be consumed by the packagers? If
> >> this is synchronized with the release schedule for Gears, why not to u=
se
> >> the same versioning schema?
> >=20
> > The version each application uses it's decided by each application auth=
or
> > (but they must guarantee it's increasing in each relase, if they don't
> > so, they are failing their duties).
>=20
> Ok. This still doesn't answer the last question.
>=20
> To re-phrase this inconsistency differently, I fixed BUG 491204
> yesterday and I was not sure which version to use for "FIXED IN".=20

The version of the application that is fixed, so 2.6.x

> If
> it's 24.12, how should the user know they got this version if they see
> 2.6.x in the about dialog? If it's 2.6.x, how should the user know they
> are going to get it with the next release of Gears being 24.12?

There is no easy way for them to know that 2.6.x will be part of KDE Gear=20
24.12 unless you write it in the bug.

If you don't like the current semantic versioning scheme used in KNights an=
d=20
would to use calendar versioning, proposed a Merge Request and see what oth=
ers=20
have to say, personally I don't care either way.

Cheers,
  Albert

>=20
>=20
> --
>=20
> Alexander