-
Notifications
You must be signed in to change notification settings - Fork 0
Guidelines
For a greater project it is really important to provide a clear structure and easy-to-read code. To achieve this please follow the following instructions.
- Branching
- Creating a new plugin
- Extending an existing plugin
- Versioning
- Re-use of features
- Dokumentation
The master branch is holding working and tested source code of every released plugin.
For each development process (features/ plugins/ bug fixes) the modifications are separated into an own brach. When the development is finished the code will be tested and inserted into the master branch if it succeeds.
Example: There is a plugin called Welcome that sends a welcome message each time a player joins. A new feature is planned where the joining player can disable this behaviour via a command. A new branch called welcome-development is created and the development starts. After completion a new pull request is created and the code is tested on various servers. It succeeds and the pull request is merged into the master branch.
Hint: The branch names should always be lower-case. Branches for development should start with the plugin name followed by -development or -dev.
[ Go to top ]
Each plugin is separated into its own project. To add a new plugin, create a new branch for the development. Switch to the newly created branch and create a new project with the plugin name. Include a plugin.yml with all relevant plugin information. Add the plugin to the master branch via a pull request.
Example: A new plugin is planned that gives all new players a starting kit. A new branch called kitplugin-development is created. The plugin project is inserted into this branch and new commands are registered via the configuration file.
Hint: A server owner should be allowed to modify the behaviour and functionalities of a plugin. Therefore a plugin should include a config.yml or other configuration files with default values.
Hint: For the version of the plugin see versioning.
[ Go to top ]
To leave the master branch untouched, create a new branch for the development. Switch to the newly created branch an start the development. After completion create a pull request to the master branch.
[ Go to top ]
The version number of the plugins is separated into three numbers. The first number indicates the release. It changes primarily when fudamental API changes were made. The second number identifies the build number. It increases every time a method or a feature is added and the structure did not change. The third and last number indicates changes like bug fixes or internal improvements. It represents the patch number.
Example: The first release of a plugin is about to be published. The version is changed from 0.50.1 to 1.0.0. After a short amount of time using the plugin a minor bug occurs. Fixing the issue changes the version of the plugin to 1.0.1. Meanwhile the developer is working on a new feature for spawning trees inside caves. He releases the new version 1.1.0 of the plugin. After a year he want to integrate the plugin into a set of plugins. Therefore he has to change the folder structure and the names of the files. The new plugin is published with the version 2.0.0.
[ Go to top ]
It is good practice to re-use existing structures and code. To share basic features like i.e. Formatters across multiple plugins use the CorePlugin. Update the existing code of the plugin and integrate the plugin in your plugin description file as a dependency.
Hint: Make sure you compare the version with the minimum version of the CorePlugin required.
[ Go to top ]
Documentation and configuration options should always be published and updated with every release. Therefore each plugin project should contain a readme file inside the root folder that describes the basic features. Additionally, each plugin should provide detailed information on the website containing a version history, configuration options, command descriptions and developer hints.
More detailed information are provided here.
Hint: The website information can also include planned features.
[ Go to top ]