Maintenance Rules

This document explains the rules for maintaining the Park-Manager project (that is the code & documentation hosted on the main park-manager/park-manager Git repository).

These rules are specific to Core Team Members as listed in Park-Manager Core Team.

Common rules

  1. Configure your global Git to sign all commits (and tags);
  2. Don’t commit changes directly to a main repository branches, for example don’t push to the master branch directly. Use pull requests instead;
  3. Don’t create new release unless being asked by the Project Leader;
  4. Only merge pull requests using HubKit, and follow the Pull Request Checklist
  5. Don’t change GitHub repository labels (https://github.com/park-manager/park-manager/labels) and topics unless being asked by a Project Leader or Lead Developer;
  6. Don’t close an issue/pull request unless a proper reason was given;
  7. Don’t lock and issue/pr unless it violates the Code of Conduct or is a security patch provided by the Core Team;

Note

In exception to rule nr. 2 small CS/spelling fixes to a recently merged pull request are allowed but should be avoided.

Any functional changes must always be provided with a pull request.

Releases

New releases are coordinated by the Project Project Leader. Core Members handling a release are revered to as Release Managers.

Note

Issues and pull request are managed using milestones, when a release is created for a specific milestone (for example 1.2) all open pull request and issues must be moved to the next possible milestone (for example 1.3).

Creating a new release

Before any release is created, the following things need to be confirmed:

  1. The correct branch is checked-out;
  2. A patch release contains only bug fixes and no new features;
  3. The UPGRADE instructions are up-to-date and properly formatted;
  4. The release title doesn’t violate any registered trademarks and has not been used previously.

Releases are created using HubKit which ensures:

  • The Git tag is signed;
  • A GitHub release page is created (with a proper changelog);
  • Split repositories are synchronized;
  • Version numbers are continuous;

To create a new release simply run hubkit release followed by the version number or patch/minor/major respectively.

$ hubkit release minor

This process might take some time as all split repositories are updated and tagged, existing tags in split repositories are automatically ignored.