Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
74 lines (54 loc) · 2.38 KB

CONTRIBUTING.md

File metadata and controls

74 lines (54 loc) · 2.38 KB
Raw

Contributing to RedstoneReboot

This repository builds multiple platform targets from one shared restart engine. Keep changes scoped, tested, and documented.

Prerequisites

  • Java 17 and 21 toolchains for the stable modules
  • Java 25 and Gradle 9.7.1 for the separate 26.x ports
  • Git
  • A test server for the platform you touched when behavior changes need runtime verification

Setup

git clone https://github.com/DemonZ-Development/RedstoneReboot.git
cd RedstoneReboot
./gradlew build

Artifacts are written under each module's build/libs/ directory.

Repository Layout

RedstoneReboot/
|- common/      Shared restart engine, scheduling, backend, and command logic
|- bukkit/      Bukkit, Spigot, Paper, and compatible plugin entrypoint
|- folia/       Folia plugin entrypoint and scheduler integration
|- fabric/      Fabric server module
|- forge/       Forge server module
|- neoforge/    NeoForge server module
|- modern/      Separate Minecraft 26.1, 26.2, and 26.3 mod builds
|- wiki/        User & Developer API documentation
|- marketplace/ Store listing copy
`- assets/      Images and branding assets

Workflow

  1. Create a branch for the change.
  2. Keep shared logic in common unless a platform-specific API is required.
  3. Update platform modules only where the platform adapter actually differs.
  4. Run ./gradlew build.
  5. Test on a server when the change affects commands, scheduling, alerts, loader startup, or shutdown behavior.

Code Guidelines

  • Keep common free of direct platform imports.
  • Match existing Java style and package structure.
  • Prefer small, explicit changes over broad refactors.
  • Use the logger style already present in the module you are editing.
  • Update tests when constructor signatures or shared logic change.

Documentation Expectations

If your change affects users, operators, or integrators:

  • update the relevant page in wiki/ (including wiki/Developer-API.md for API changes)
  • keep README links and command/config examples aligned with the code

Pull Requests

Good pull requests usually include:

  • what changed
  • why it changed
  • how it was tested
  • any config, command, or migration impact

Need Help