We will abide by the Amethyst coding conventions unless otherwise specified.
The latest stable rust toolchain version of
rustfmt must be used in all the code bases. This will be enforced by CI. Clippy is not enforced but can be used to improve the code quality.
GitHub issues & releases
- Next major release is always tracked in a milestone version (0.1, 0.2, 1.0 etc)
- any stand-alone tasks should be labeled as such and is not tied to any specific milestone, i.e. it can be worked on and completed at any time.
- any major feature (I.e. not stand-alone) not due for the next immediate release should only exist as a design topic on Discourse until the spec is ready for implementation.
If you commit to doing something, we can reserve that task for you for a week. If there is no sign of any work having started after a week-long reservation, the task will be considered up for grabs again,
We will follow the Semver standard, liberally adapted to game development practices.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when releasing a radically different iteration of the game, e.g. going from 2D to 3D.
- MINOR version when adding new features
- PATCH version when fixing bugs, make balance changes or patch something.
Rebasing & squashing
I think it would be great to decide on rebasing & squashing as a merge strategy. It makes the history a lot clearer and linear (one commit per PR). In that case we should have one PR per feature.
Otherwise we will often have small commits, like ‘Fix formatting’ that are not really necessary in the history of the master branch.