[Kde-games-devel] libkdegames v5

[Parker Coates]

On Mon, Jan 30, 2012 at 12:16, Stefan Majewsky wrote:
> The change to Qt 5 is the ideal opportunity to break binary compatibility.

Really, there's nothing stopping us from breaking binary
compatibility. libkdegames has never promised to maintain ABI across
all of 4.x, so as long as we bump the SO number, we could start
tearing out code today.

> The
> first obvious point is to move the carddeck stuff into libkcardgame. Wasn't
> this intended to become public API at some point anyway?

Yes, it was, but
 a) the API isn't yet documented
 b) no new games showed up wanting to use libkcardgame to pressure me
to finish it
 c) my efforts to port LSkat to libkcardgame never got very far as
that codebase is very ... um ... interesting.
 d) my daughter was born and periods of free time longer than 10
minutes disappeared

Other than d), it's c) that is actually the biggest hurdle, because
until LSkat is ported the card decks can't be moved into libkcardgame
and the old card handling code in libkdegames can't be removed.

> Most of our games are already barely maintained. We shouldn't risk breaking
> third-party games by offering API which we cannot guarantee works because we
> don't even use it ourselves.

I realise that libkdegames is public API, but does it actually have
any users outside of kdegames, extragear/games or playground/games? Or
is all this discussion purely academic? According to the (fairly
extensive) Debian repositories, the only game depending on libkdegames
not hosted in any of the above locations is Tagua, which as far as I
know is no longer in active development. Is that right, Paolo?

> Possible resolutions for how to remove classes from public API include:
>
> 1. Delete the code.
> 2. Keep the code in libkdegames, do not install the header. (The API is only
>   available to existing games in the kdegames module.)
> 3. Move the code into a libkdegames_private, do not install the header.
>   (Functionally equivalent to 2, but the code is at a different place.)
> 4. Move the code into the source tree of the only game using it.

I vote for 1 or 4 depending on the code in question. We use version
control for a reason. If someone one wishes to use the old code,
there's nothing stopping them from taking it from a previous revision.

Parker