You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.**
5
-
6
-
## Code formatting and comments
4
+
Ways to contribute
5
+
-----------------------
6
+
-**Beta testing**:
7
+
- Download and install builds from the `beta` branch. Provide feedback to our developers and file any issues that you come across on [GitHub](https://www.github.com/hestiacp/hestiacp/issues).<br>
8
+
`v-update-sys-hestia-git hestiacp beta install` will install the latest beta build from our GitHub repository.
9
+
-**Code review and bug fixes**:
10
+
- Read over the code and if you notice errors (even spelling mistakes), submit a pull request with your fixes.
11
+
-**New features**:
12
+
- Is there an awesome feature that you'd love to see included? While our development team tries to fulfill all reasonable requests, it can take time to implement new features depending on the amount of work involved. Submit a pull request with your code and if your idea is approved, we'll review and test it for inclusion with an upcoming release.
13
+
-**Translations**:
14
+
- If you are a non-English speaker and would like to improve the quality of the translations used in Hestia Control Panel's web interface, please review the `.php` files found under `hestiacp/web/inc/i18n` and submit a pull request or open an issue report [GitHub](https://www.github.com/hestiacp/hestiacp/issues) highlighting the issue with the current translation so that it can be corrected.
15
+
-**Donations**:
16
+
- If you're not a developer but you still want to make a contribution, you can make a donation to the Hestia Control Panel project to further its development (or if you'd just like to buy our developers a lunch, we'd appreciate that too). We currently accept dontations through [PayPal](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=ST87LQH2CHGLA).
17
+
18
+
Development Guidelines
19
+
-----------------------
20
+
### Code formatting and comments
7
21
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.
8
22
9
-
## Working with branches
10
-
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:
23
+
### Workflow and process
24
+
Development for this project takes place in branches to effectively develop, manage, and test new features and code changes. Our tiered approach allows us to closely control the quality of code as it is checked in for inclusion.
25
+
26
+
We have three primary or "evergreen" branches, which exist throughout our product's lifetime. Please refer to the following table for a description:
|`main`| Contains a snapshot of the latest development code.<br>**Not intended for production use and may be unstable.**| Daily |
15
-
|`beta`| Contains a snapshot of the next version currently in testing.<br>**Accepts bug fixes and code clean-up only!**| Weekly |
16
-
|`release`| Contains a snapshot of the latest stable release.<br>**This code aligns with the packages released via apt**| Monthly |
31
+
|`beta`| Contains a snapshot of the next version which is currently in testing.<br>**Not intended for production but should be highly stable.**| Weekly |
32
+
|`release`| Contains a snapshot of the latest stable release.<br>**Intended for production use. Same code as packages in repository.**| Monthly |
17
33
18
34
### Creating a new branch and submitting pull requests
35
+
The first step is to create a fork of the `hestiacp/hestiacp` repository under your account so that you may submit pull requests and patches via GitHub.
19
36
20
-
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.
21
-
22
-
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:
37
+
Once you've created your fork, clone the repository to your computer and make sure that you've checked out the `main` branch. **Always** create a new topic branch for you work. When submitting pull requests it is important that you 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:
23
38
24
39
### Branch naming convention:
25
40
-**Prefix:**`topic/` (such as **bugfix**, **feature**, **refactor**, etc.)
@@ -31,32 +46,61 @@ Branch name examples:
31
46
*`feature/777_my-awesome-new-feature` or `feature/2020-07_my-other-new-feature`
32
47
*`fix/000_some-bug-fix` or `fix/2020-07_this-feature-is-broken`
33
48
*`refactor/2020-07_v-change-domain-owner`
34
-
*`test/2020-07_main-domain-ssl`
49
+
*`test/2020-07_mail-domain-ssl`
50
+
51
+
### Squashing commits for smaller changes
52
+
When submitting a pull request with multiple smaller commits which are related to the same file or issue, we ask that you please **squash your commits** whenever appropriate in order to keep the project's commit history clean and easy to follow for other developers.
35
53
36
-
To better understand our branch structure, please refer to the following table:
54
+
### What happens when I submit a pull request?
55
+
- Our internal development team will review your work and validate your request.
56
+
- Your changes will be tested to ensure that there are no issues.
57
+
- If changes need to be made, you will be notified via GitHub.
58
+
- Once approved, your code will be merged to the appropriate `staging/*` branch based on the chart below:
37
59
38
-
### Git branch target workflow:
60
+
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.**
39
61
40
-
| Topic branches: | Target: | Final destination: |
-`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.
50
-
-`staging/*` branches are integrated into `main` at various intervals throughout the development process until all planned work items are integrated.
51
-
- Once a new version is ready for testing and validation, a snapshot of the code from `main` is merged to `beta`.
52
-
- When the `beta` release is ready to move to production, the code is then pushed to `release`.
53
-
- 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.
70
+
Our development and release cycles
71
+
-----------------------
72
+
### During the development cycle:
73
+
-`topic/*` branches are submitted to our team via a pull request. Your changes will be reviewed and tested, and if all appropriate quality assurance checks pass the branch will be merged to the corresponding `staging/*` branch.
54
74
55
-
## Squashing commits for smaller changes
56
-
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.
75
+
-`staging/*` branches merge into `main` at various intervals throughout the development process.
57
76
58
-
**IMPORTANT: Please ensure that all pull requests meet the guidelines listed above; those that do not will be rejected and sent back for review.**
77
+
- When all planned features and fixes have been merged to `main`, the code is tested for regressions and bugs.
59
78
60
-
Donations
79
+
- A snapshot of `main` is pushed to a temporary branch called `staging/refactoring`, and final code review, refactoring, and optimization takes place. Once complete, `staging/refactoring` merges back to `main` bringing the codebase up-to-date. All other `staging/*` branches synchronize with `main` at this time.
80
+
81
+
- After final validation checks pass, our development team signs off on the release and the code is pushed from `main` to `beta`.
82
+
83
+
### During the release cycle:
84
+
-**What happens when code moves from `main` to `beta`**:<br>
85
+
-**No new feature requests will be approved**.
86
+
-`main` will receive an increment in it's version number signaling the start of a new development cycle.
87
+
-`fix/*` topic branches/commits will be cherry picked to `beta` as necessary.
88
+
-`staging/docs` will merge into `beta` prior to the code being pushed to `release` to bring documentation and supporting files up-to-date.
89
+
90
+
- If all quality assurance checks pass, our development team will then:
91
+
- Sign off on the code in `beta`.
92
+
- Push the code to the `release` branch and create a corresponding version tag.
93
+
- Compile new packages and publish them to our APT repository.
94
+
-**Notes:**
95
+
-`release` always contains the highest released version of Hestia Control Panel.
96
+
- For major releases, a `release/vX.x` branch will be created for maintenance and servicing purposes.
97
+
98
+
99
+
100
+
101
+
Thank you!
61
102
-----------------------
62
-
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](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=ST87LQH2CHGLA).
103
+
We appreciate **all** contributions no matter what size; your feedback and input directly shapes the future of Hestia Control Panel and we could not do it without your support.
104
+
105
+
Thank you for your time and we look forward to seeing your pull requests,<br>
0 commit comments