hestiacp/CONTRIBUTING.md

Code Contributions & Pull Requests - Guidelines

All pull requests must include a brief but descriptive title, and a description of the changes that you've made with as much detail as possible. Only include commits that are related to your feature, bug fix, or patch in your pull request.

Code formatting and comments

We ask that you follow existing naming schemes and coding conventions where possible, and that you add comments in your source code where appropriate to aid other developers in debugging and understanding your code in the future.

Working with branches

Development for this project takes place in branches to effectively develop, manage, and test new features and code changes, helping to ensure that each release meets high quality standards. Our primary branches are as follows:

Branch	Description	Cycle
main	Contains a snapshot of the latest development code. Not intended for production use and may be unstable.	Daily
beta	Contains a snapshot of the next version currently in testing. Accepts bug fixes and code clean-up only!	Weekly
release	Contains a snapshot of the latest stable release. This code aligns with the packages released via apt	Monthly

Creating a new branch and submitting pull requests

The first step is to create a fork under your account on GitHub. This will provide you with your own copy of the code to work with at any time.

Next, create a new topic branch for your work. When submitting pull requests, it is important to target the correct branch to ensure that your changes are properly integrated and tested based on our release schedule. When creating a new branch, we ask that you please adhere to the following naming conventions as much as possible:

Branch naming convention:

• Prefix: topic/ (such as bugfix, feature, refactor, etc.)
• ID: 888 (GitHub Issue ID if an issue exists) -or- 2020-07 (Year-Month if an issue does not already exist)
• Separator: _ (underscore)
• Title: my-awesome-patch

Branch name examples:

• feature/777_my-awesome-new-feature or feature/2020-07_my-other-new-feature
• fix/000_some-bug-fix or fix/2020-07_this-feature-is-broken
• refactor/2020-07_v-change-domain-owner
• test/2020-07_main-domain-ssl

To better understand our branch structure, please refer to the following table:

Git branch target workflow:

| Topic branches: | Target: | Final destination: | | -----------------------------|:-----------------------:|:----------------------------:| | feature/* | staging/features | main | | fix/* | staging/fixes | main or beta | | refactor/* | staging/cleanup | main or beta | | test/* | staging/tests | main | | doc/* | staging/docs | main, beta, or release |

Notes:

• topic/* branches are submitted to our team via pull request for eventual inclusion into the main code branch and a future version of Hestia Control Panel.
• staging/* branches are integrated into main at various intervals throughout the development process until all planned work items are integrated.
• Once a new version is ready for testing and validation, a snapshot of the code from main is merged to beta.
• When the beta release is ready to move to production, the code is then pushed to release.
• Each major version (such as v1.1, v1.2) will also have a corresponding release/vX.x version branch for archival and maintenance/servicing purposes.

Squashing commits for smaller changes

When submitting a pull request with multiple smaller commits which are related to the same issue (or file), we ask that you please squash your commits in order to keep the project's commit history clean and easy to follow for other developers.

IMPORTANT: Please ensure that all pull requests meet the guidelines listed above; those that do not will be rejected and sent back for review.

Donations

If you would like to make a donation to the Hestia Control Panel project to further its development (or if you'd like to buy our developers a lunch), please feel free to do so via PayPal.