Re: Game module versioning

[Stan Shebs <shebs at shebs dot cnchost dot com>]

Nick Williams wrote:
> 
> another thought: look at the version the other way around. Why not put the
> version of xconq which is required/wanted into the game file. With an
> optional parameter or something saying the game is prod or dev, which
> defaults to prod:

What you're describing is more like the program-version property,
which I recently removed because it's been in there for several
years and never been used.  It would actually be hard to ensure
correctness across a range of major releases, because each has
different GDL and different behavior.

The big problem with the game library is that it consists of a mix
of finished and unfinished designs, but it's not clearly identified
when a game gets to a finished stage.  It can be very frustrating
for would-be players to start up a cool-sounding game, only to find
no documentation, and no clear idea of how to play it!  So we need
a way to guide new players to the finished games, while providing
developers and designers with a way to look at all the games.

So here's my modified proposal that accounts for Hans' concerns.
game.dir lists all games that could reasonably be launched,
excluding only support modules.  Then have two checkboxes:
first one says "List unfinished games also" and the second
says "List all games".  To get on the default list, the game
must have a version of "1.0" or greater.  The unfinished games
have versions "0.x", while the rest of the games can have anything
for versions, or no version info at all.  So in the case of a retired
game ("Classic" for instance), its version would be "(retired) 1.0".

Stan