Development Process

This page describes the general development process of Cyclops mods

Mod structure

Source code

All mods are available open-source on GitHub under the CyclopsMC organization.

In order to reduce code duplication, common code between mods is shared in CyclopsCore. This mod is therefore a dependency for all other mods.

Releases are published on CurseForge.

Development builds are published on GitHub packages.

Branch management

For every major Minecraft version, two branches exist:

• master-[mc-version]: Latest (potentially unstable) development.
• release-[mc-version]: Latest stable release for that Minecraft version. This is also tagged with all mod releases.

Issue Management

Project boards

• Maintenance: Bugs, questions, performance issues, and others.
  • Decomposed into on-hold, todo (minor), todo (major)
• Features: Optional and accepted features.

Issues in the maintenance board are considered more important than those in the features board, as we aim to achieve stability over new features.

Issue creation

Issues across all Cyclops repos use the same issue templates:

• 🐛 Bug report: If something is not working as expected or crashes
• ➕ Feature request: Suggest an idea for this project
• 🐌 Performance issue: An issue with the performance of this mod, such as abnormal lag.
• ❓ Question: A general question
• Other...

Using GitHub workflows, the following automation occurs when issues are created:

• Label new issues: Based on the issue template, the proper issue label is attached (bug, feature-long-term, performance, question). Additionally, a label for the relevant Minecraft version is attached.
• Comment on issues by label: Based on the issue template, a comment to thank the issue creator is placed.
• Add labeled issues to project board: Based on the issue template, the issue is added to the features project board )(for features) or the maintenace project board (for all others).

When an issue uses the wrong issue template

If an issue does not conform to the issue template, the invalid-template label can be added. This will cause a comment to be placed asking the creator to update the issue. If no changes are done within 7 days, the issue is closed.

When more information is needed

If more information is needed from the issue creator, the more-information-needed label can be added. This will cause the issue to be automatically closed after 14 days when no further comments are received.

Labels

Issue labels across all repos are identical.

Important to mention is that a label exist for all (major-minor) Minecraft versions (mc-x.xx).

New labels can be added and synchronized across all repos via this tool.

Release process

When a release will be made, the CLI tools from the ReleaseHelpers repo should be used.

When installed, a release is made as follows:

1. Navigate to the mod repo on the CLI
2. Execute cc-changelog [major|minor|patch]

• This will bump the mod version and create a new changelog file under resources/changelog/ based on the git log since last release.

3. Edit the new changelog in resources/changelog/ (categorize commit messages under the correct strategies)
4. Execute cc-release (requires signed commits)

• This will create a commit, merge changes with release-[mc-version], create a git tag, and push.
• After this, Travis will automatically take care of the release publication to CurseForge once it builds the new tag.

WARNING: when making a first release for a new Minecraft version, make sure that a release-[mc-version] branch exists before calling cc-release! This can be done by executing git checkout -b release-[mc-version] && git checkout master-[mc-version].

Version checker

Every night, Forge update files are auto-generated for CurseForge mods that are mentioned in this file. This is done using the tool forge-update-generator.js via a scheduled GitHub Action.

Managing files across all mod repos

When changes need to be made across all repos (e.g. the GitHub issue templates), git-multi-repo.sh can be used.