[Kde-games-devel] libkdegames v5

[Albert Astals Cid]

El Dilluns, 30 de gener de 2012, a les 18:16:11, Stefan Majewsky va escriure:
> Hi everyone,
> 
> while I have not been active in development lately, I have been monitoring
> the developments in KDE land, especially the development of Qt 5 and
> kdelibs 5 (aka "frameworks"). This makes me wonder how we should react to
> this in kdegames, as we also maintain a public library, libkdegames.
> 
> The change to Qt 5 is the ideal opportunity to break binary compatibility.
> The first obvious point is to move the carddeck stuff into libkcardgame.
> Wasn't this intended to become public API at some point anyway?
> 
> ===== 1. API cleanup =====
> 
> But that is just the low-hanging fruit. I want to argue for using this
> opportunity to remove large bits of libkdegames from the public API, and
> also fix some minor annoyances. I would like to go as far as removing the
> following things from the public API:
> 
> 1. KGameCanvas
> 2. the KGame framework
> 3. unused stuff like KGameSvgDigits, KGameProgress or KGameMisc
> 4. KGGZ
> 
> KGameCanvas is probably the only non-controversial point here: New
> applications should really use QGraphicsView or QSceneGraph from Qt 5.
> Please note that I'm not voting for deleting this code, I want to remove it
> from the public API. This just means to not install header files for these
> classes anymore.

This (not install headers) is going to be difficult if we go to the split repo 
mode.

> 
> For all the other points, this step may sound rude, because this code is
> perfectly working at the moment. The reason for this proposal goes deeper
> than that.
> 
> A shared library with a public API, especially if it has regular releases
> like libkdegames has, comes with an implicit maintenance promise. If one
> provides a regularly updated interface, third parties will assume that the
> library itself is also maintained.
> 
> As a counter-example, the last commit on libkdegames/kgame (except for the
> usual style fixes) was in late 2008. And that was the only substantial
> commit that year. KGame is only used by KFourInLine and KSirk, by the way.
> 
> 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.
> 
> The case of KGGZ is special. It is said to work, but I cannot recall seeing
> it work. The only person who knows the code (Josef) has not been able to
> merge his rewrite since four years. (No offense meant, I know about his
> work obligations.)
> 
> In the special case of KGGZ, I vote for removing it both from the library
> and from applications. I cannot see how it provides value for users, and I
> feel that its mere existence constitutes a mental barrier for those who
> want to introduce multiplayer functionality into our games using different
> technologies. (I recall myself being skeptical towards a proposal of using
> Telepathy for multiplayer functionality in a non-KGGZ-powered game, because
> KGGZ existed already.)
> 
> tl;dr: Let's remove most of the public API of libkdegames, at least as long
> as we can't fulfill the implicit maintenance promise.

Agreed.

> My detailed proposal is to compile a list of all API which we want to remove
> depublicize in libkdegames 5, and mark that API as deprecated. 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.

If we can't/don't want to maintain it either 1 or 4, that is kill it or shift 
the responsability to the game using it.

Albert