[Kde-games-devel] Re: Move Tagaro code into SVN?

[Parker Coates]

On Mon, Apr 18, 2011 at 12:28, Stefan Majewsky wrote:
> Having said that, I'm also fine with kdegames moving to Git and
> libtagaro.git being integrated into that (in whatever fashion). The
> only thing that really matters for me is to have Tagaro available as a
> hard dependency in kdegames. That has to happen before the feature
> freeze, preferably before the hard feature freeze so I can take
> advantage of it in the 4.7 release already. This unavailability of
> Tagaro blocks like everything else I want to do (including good sound
> support in all games, more Kolf refactoring, and mobile interfaces).
>
> And by the way, can someone please explain to me how a private library
> like Tagaro is possible without installed headers for split repos?

Could you explain why you want Tagaro to be private, again? To me, it
seems the simplest solution to this whole situation would seem to be
to make Tagaro a separate, kdesupport-style library. If that were
done, the plan could be:

 1. Keep Tagaro in git.kde.org
 2. Add the Tagaro dependency for games X, Y and Z to the feature plan
before April 28th
 3. Get the current state of Tagaro through kdereview before May 12th
 4. Make a 0.1 release of Tagaro before May 12th
 5. Make the relevant games within the SVN module depend on Tagaro
0.1.x depend on Tagaro before May 12th.
 6. Release Tagaro 0.1.1, 0.1.2 and so on if necessary for bug fixes.
 7. Release KDEGames 4.7
 8. If new API is needed, release Tagaro 0.2. If the changes are
binary incompatible, also bump the SO version.
 9. Port all games using Tagaro to Tagaro 0.2 (if porting is
explicitly necessary) and bump the version number of the Tagaro
dependencies.
 10. repeat from 6.

Note that this plan really doesn't depend on if/when KDEGames moves to
Git and whether the repository is monolithic or split.

While binary compatibility is nice, there's no reason for a brand new,
non-core library to be held back by it. And as long as only games in
the module are using Tagaro and all games are ported to a new version
before the next SC release, I highly doubt distributions will have to
worry about keeping multiple versions of Tagaro installed
simultaneously.

Of course, there may be a obvious hole with this plan that I'm just
not seeing. And of course the timeline is a little tight to make a
first release. (I'm not sure how release-ready the current libtagaro
is.) I guess one downside is that Tagaro wouldn't officially be a part
of the KDEGames module, but I think that has more benefits than it
does drawbacks currently. In the future, once it stabilises, there
would be nothing stopping it from entering the module.

It just seems a lot easier to do things out in the open using a
traditional versioning scheme, release schedule and version
dependencies, than it is to worry about private versions and
uninstalled headers and such.

Parker