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

[Parker Coates]

On Mon, Apr 18, 2011 at 16:22, Parker Coates wrote:
> 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.

Now that I've thought about it, I think the above is probably more
complicated than necessary. I don't see any reason that Tagaro
couldn't be part of the module and release with the module. It just
wouldn't promise binary compatibility between releases (at least at
first). Provided they update the SO version appropriately, there's no
requirement that all public libraries in KDE modules must keep BC.

I still think it might be wise to live Tagaro in git for SC4.7 to
avoid having to convert it to SVN and back to Git. The KDEGraphics
module is split between SVN and Git, so I don't see why we couldn't be
as well.

Parker