You want to contribute? That's great! Welcome aboard. First of all see these links for general guidelines for contributing to open source.
- The GitHub Actions CI build and AppVeyor build (which also run the test suite) should pass on each commit.
- Your contributions should be under GPLv3+ or a compatible free software licence, but please don't put them under the AGPL, which adds additional restrictions.
- The code should be compatible with Python 3.7 and above.
- Translate PySol to a human language you know.
- Test the "master" branch version of the version control repository or other prereleases.
- Try to reproduce open issues
- Try to fix bugs.
- Add new games.
- Improve the documentation / online help
- Refactor the code.
- Add new features.
- Contribute graphics
- Improve the site
- Package PySol for a new package repository or OS, or update existing packages.
- Make a monetary donation.
- Star or Watch the repository on GitHub
First of all there is the "Solitaire Wizard" which may be used to generate many custom variants. It lives in the Edit menu.
Otherwise, the games' sources live under the pysollib/games/ directory in the repository, and are written in Python 3.x and you can try inheriting from an existing variant class.
In addition to adding the game's source code, be sure to add the game's metadata. At minimum, you should:
- In html-src/rules, create a rules file for the game in question. Use an existing rules file as a guideline. Ideally, each set of game rules should be written in such a way that a non-PySol user can read the rules and know how to play the game with their own deck of cards. For games that are only slightly different from other games, referencing the more common variant's rules is okay.
- In the pysollib/gamedb.py file, update the GAMES_BY_PYSOL_VERSION dictionary to include the new game's ID for the "dev" key. If the "dev" entry does not exist, add it.
- If you know the inventor for the game, update the inventor's entry in the GAMES_BY_INVENTORS dictionary in the same file.
One can contribute changesets either by opening pull-requests or merge requests, or by submitting patches generated by git diff or git format-patch to a developer's email (e.g @shlomif's ) or uploading it to a web service (e.g: a pastesite, dropbox, or Google Drive).
Before publishing a release, please open an issue in GitHub, indicating your intent to do so, to confirm with any other developers if they have any objections, or any WIP features/tickets that should be included in the upcoming release. It's best to do this a week or two before you plan to actually publish the release. No responses on this for a couple weeks can be considered approval to proceed. Releases tagged without verifying with other developers may be removed.
In order to publish a new version, follow these steps:
- Update
NEWS.asciidoc
. The release notes should also be added tohtml-src/news.html
, along withtemplates/index.html
in the website repo. - Update the
VERSION_TUPLE =
line inpysollib/settings.py
. - Check the
GAMES_BY_PYSOL_VERSION
dictionary in thepysollib/gamedb.py
file. If there's a "dev" entry in this dictionary, change that entry's key to be the new version number. If there isn't a "dev" entry, ignore this step. - Test using
gmake test
. git commit
the changes .git tag pysolfc-2.6.5
(or equivalent version).git push
andgit push --tags
to https://github.com/shlomif/PySolFC .- Wait for the AppVeyor build for the tag to complete and scan the .exe using https://www.virustotal.com/ .
- Grab the macOS installer (.dmg) from GitHub Actions (look for an artifact called
pysolfc-dmg
). - Run
gmake dist
. - Use rexz9 on
dist/PySol*.tar.xz
. - Go to https://sourceforge.net/projects/pysolfc/files/PySolFC/ and add a folder called PySolFC-2.6.5 (note the capitalisation).
- Add the tar.xz, the .exe and the .dmg there and mark them as defaults for the right OSes.
Support SVG cardsets.
An optional REPL (Read-eval-print loop)
Listen on a TCP / HTTP+REST port.
A web-based version.
Support a more secure saved-games format than the pickle-based-one.