-
Notifications
You must be signed in to change notification settings - Fork 53
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
26 additions
and
23 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,35 +10,36 @@ The following is a set of rules for contributing to **Rucio** and its | |
| packages. Use your best judgment, and feel free to propose changes to this | ||
| document. | ||
|
|
||
| If you have questions, you can reach the core development team on our | ||
| [__Mattermost__](mattermost.md) channel, or send an email to our | ||
| development mailing list [__[email protected]__](mailto:[email protected]). | ||
| If you have questions, you can reach the development team on our | ||
| [__Mattermost__](mattermost.md) channel. | ||
|
|
||
| ## What should I know before I get started | ||
|
|
||
| A contribution can be either be a **patch** or **feature**: | ||
| A contribution can be either be included in the **next** major release or the | ||
| ongoing **current** release line, e.g. `release-33` This becomes relevant when | ||
| naming the branches of your contributions (See section 3) so the Rucio maintainers | ||
| can understand the targeted release. | ||
|
|
||
| * **Patches** include bugfixes and minor changes to the code and are included in | ||
| patch releases usually made on a bi-weekly schedule. | ||
| * **Features** include major developments or potentially disruptive changes and | ||
| are included in feature releases made multiple times a year. | ||
| * Larger feature developments, backwards-compatibility breaking changes, changes | ||
| to the database schema, significant changes to the REST interface, and similar | ||
| **MUST** be targeted to the **next** release line. | ||
| * Bugfixes, smaller backwards-compatbile changes to the REST interface, smaller | ||
| feature developments, and similar **CAN** be targeted to the **current** release | ||
| line. | ||
|
|
||
| The [__repository__](https://github.com/rucio/rucio/) consists of different | ||
| branches: | ||
|
|
||
| * the **master** branch includes the development for the next major version. | ||
| * the **release-…** branches include the patch/minor development of the | ||
| releases. | ||
|
|
||
| Release branches only exist for the currently maintained release | ||
| versions. Hotfix branches are created on demand. Please communicate to the Rucio | ||
| maintainers, if you wish to hotfix a previous release. | ||
| * the **master** branch includes the developments for the next major release. | ||
| * the **release-…** branches include the patch/minor developments of the | ||
| releases (Such as current and LTS releases). Release branches only exist for | ||
| the currently maintained releases (See the [release policy](started/releasepolicy.md)) | ||
|
|
||
| Generally all [__pull requests__](https://github.com/rucio/rucio/pulls) are to | ||
| be created against the Rucio **master** branch. Features will end up in the | ||
| upstream **master** only and patches are cherry-picked to the maintained | ||
| releases if applicable. Release-specific changes are excluded from that rule and | ||
| might be needed if e.g. cherry-picking to the last release was not successful. | ||
| be created against the Rucio **master** branch. Pull requests named/targeted for | ||
| the **next** major release will end up in the upstream **master** only. Pull | ||
| requests named/targeted for the **current** release will be additionally | ||
| cherry-picked to the applicable release branch. | ||
|
|
||
| The following figure might help you with an overview: | ||
|
|
||
|
|
@@ -105,16 +106,18 @@ number**. | |
| Create a local branch that corresponds to the issue. To easily | ||
| identify the purpose of branches different keywords must be used: | ||
|
|
||
| * Patch branches must be named **patch-[issue number]-[short description]** | ||
| * Feature branches must be named **feature-[issue number]-[short description]** | ||
| * Contributions targeted to the **current** release must be named | ||
| **current-[issue number]-[short description]** | ||
| * Contributions targeted to the **next** major release must be named | ||
| **next-[issue number]-[short description]** | ||
|
|
||
| If you create these branches by hand please check the spelling because otherwise | ||
| the test automation might misidentify your branch. There are utility scripts to | ||
| fetch master and create these branches for you: | ||
|
|
||
| ```bash | ||
| ./tools/create-patch-branch <unique issue number> '<short_change_message>' | ||
| ./tools/create-feature-branch <unique issue number> '<short_change_message>' | ||
| ./tools/create-current-branch <unique issue number> '<short_change_message>' | ||
| ./tools/create-next-branch <unique issue number> '<short_change_message>' | ||
| ``` | ||
|
|
||
| ### 4. Commit your changes | ||
|
|
||