KeeperRL versioning

[Akien]

Hi miki151,

I've tried KeeperRL alpha5 and really enjoyed it, it's already quite functional and fun!

I'm considering packaging KeeperRL for the Mageia Linux distribution. Though to do so I need to set a proper version for the package, that will be consistent with later version (i.e. letter versions should be greater than it for the parser). So “alpha5” is not optimal for such things, and I wondered if you had a planned version number for the final release?

For alphas and betas, Mageia's policy is to set the target version as version, and add “0.alpha5.%{rel}”, where %{rel} is Mageia's internal package release.
So if the final version were to be 1.0, my package would be keeperrl-1.0-0.alpha5.1″.

Another possibility if you want to have the stable version be 1.0, would be for me to call the alphas “0.x”, e.g. 0.5 for alpha5.

What's your opinion about this?

It would also be great if you created git tags when you release an alpha, so that people can get the source code of a given version.

[miki151]

Hi, just use 0.0.5 for alpha5 and so on.

For now I've added a stable branch to git for the latest alpha. Is this enough?

The problem with packaging is that the game reads everything from the current directory and there is no way around it yet. I'm not sure if the package system can handle it.

[Akien]

Hi, just use 0.0.5 for alpha5 and so on.

For now I've added a stable branch to git for the latest alpha. Is this enough?

Thanks I will use 0.0.5 and the stable branch then. In most projects that I follow (and particularly on github), developers create a tag corresponding to a snapshot of the code for a given version. It enables users to download the whole code of a given version if they want to give it a try and compile it themselves. So in my opinion, if you could create a tag for your next version when you build it and upload it to the world, it would be great! Then it's up to you to do what fits you best. A stable branch is already quite good 🙂

The problem with packaging is that the game reads everything from the current directory and there is no way around it yet. I'm not sure if the package system can handle it.

In such cases the simple workaround would be to put everything in the same folder and to create a wrapper script to launch the game from its installation folder. It's not recommended though, we tend to install (game) binaries in /usr/games, data in /usr/share/games/$name/ and e.g. libraries in /usr/lib(64)/ or /usr/lib(64)/$name/

I'll see if I manage to patch your Makefile and source code to make it possible to install the binary and the data in different folders. If so I'll make sure I send it to you 🙂

[Author]

Posts