Troubleshooting the Haikuporter recipe for OpenXcom


#23

Quick question: Why not just call the nightly build of OpenXcom “openxcom-nightly”? Wouldn’t it be better to change the revision number for each new nightly build rather than make a whole new port directory?


#24

No need for new directories, you just rename the old recipe (or duplicate, rename, test and if it works, delete the old recipe).

Having the version in the recipe name has advantages. Obviously, you can see the version of the recipe without having to open it and look for the SOURCE_URI etc. Also, you may want to use the variable $portVersion in the recipe wherever you refer to the version (like in the SOURCE_URI, SOURCE_DIR etc.) to have it all auto-update when you change the recipe name.

“Nightlies” may be a special case, but I doubt you want to keep uptodate with a fast-moving app. But, for example, youtube-dl has almost weekly releases. Check its use of $portVersion to minimize the changes needed for each release.


#25

as @humdinger already pointed, no new directories needed. The games-strategy/openxcom folder can have more than one recipe, one for 1.0 and one for git master as-currentdate.

Basically version is for version bump, while revision bump mens the source is the same just some build-time option changed. We cannot really speak about version in git master, only about commits.

So to easily identify, wich git-commit used for the recipe we use the date as postfix in the recipe name, so if 6 months later somebody else try to update the recipe, it can easily find out roughly, wich git commit does this recipe using. For precise identification we have the srcGitRev in the recipe.


#26

Please read https://github.com/haiku/haiku/blob/master/docs/develop/packages/BuildingPackages.rst#version-strings

1.0 is already released, so 1.1~nightly or 1.0.1~nightly is preferred. The package management will update such a version to 1.x when a release appears as an update.


#27

I could be wrong, but I don’t think that OpenXcom changes major things like dependencies very often. The changes tend to be more code cleanups and adjustments to behavior of systems inside the game. It shouldn’t be too hard to keep with the nightlies as a result, but obviously I (or whoever the ongoing maintainer would be) would want to test new versions before updating the port. Also, the time between releases varies a lot. Sometimes, there are several weeks between builds, other times a few in a day. I think aiming for updating the port once a week would be realistic, and give time to really test out new versions properly.

Okay, that makes more sense. I was wondering about the multiple recipes in the directory as well, and now I get it.


#28

Right. Just consider that nightlies may introduce regressions etc. that can show up and get fixed only after some time. Testing by the port maintainer may not reveal the tricky ones in time. Official releases are there for a reason. :slight_smile:
Even if a nightly is “bugfree”, the gamers may not appreciate having to update too often (I don’t know the size of the OpenXcom package).


#29

It’s not massive, and the improvements are generally welcome, especially for those players who use mods.

@extrowerk, If you’re not already doing it, I’d like to add the updated logo. Converting an SVG file to HVIF rdef seems simple enough, and will let me submit a PR request as a test run for doing one for your commits.


#30

Just do it, mate.


#31

Done. I just wanted to make sure I wasn’t duplicating effort.