github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-24 01:38:56 -04:00
Code Issues Projects Releases Packages Wiki Activity

Update docs on branching. (#139057) (#139415)

Browse source 
Co-authored-by: Tyler Smalley <tyler.smalley@elastic.co>
(cherry picked from commit 9326c53baa)

Co-authored-by: Luke Elmers <luke.elmers@elastic.co>
This commit is contained in:
Kibana Machine 2022-08-24 13:45:47 -04:00 • committed by GitHub
parent dd82c775cd
commit 016f705c7e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/developer/contributing/development-github.asciidoc
View file

@ -14,16 +14,14 @@ repo, which we'll refer to in later code snippets.
At Elastic, all products in the stack, including Kibana, are released at the same time with the same version number. Most of these projects have the following branching strategy:
* `master` is the next major version.
* `<major>.x` is the next minor version.
* `<major>.<minor>` is the next release of a minor version, including patch releases.
* `main` points to the next minor version.
* `<major>.<minor>` is the previously released minor version, including patch releases.
As an example, let's assume that the `7.x` branch is currently a not-yet-released `7.6.0`. Once `7.6.0` has reached feature freeze, it will be branched to `7.6` and `7.x` will be updated to reflect `7.7.0`. The release of `7.6.0` and subsequent patch releases will be cut from the `7.6` branch. At any time, you can verify the current version of a branch by inspecting the `version` attribute in the `package.json` file within the Kibana source.
As an example, let's assume that the main branch is currently a not-yet-released 8.1.0. Once 8.1.0 has reached feature freeze, it will be branched to 8.1 and main will be updated to reflect 8.2.0. The release of 8.1.0 and subsequent patch releases will be cut from the 8.1 branch. At any time, you can verify the current version of a branch by inspecting the version attribute in the package.json file within the Kibana source.
Pull requests are made into the `master` branch and then backported when it is safe and appropriate.
Pull requests are made into the `main` branch and then backported when it is safe and appropriate.
* Breaking changes do not get backported and only go into `master`.
* All non-breaking changes can be backported to the `<major>.x` branch.
* Breaking changes can _only_ be made to `main` if there has been at least an 18 month deprecation period _and_ the breaking change has been approved. Telemetry showing current usage is crucial for gaining approval.
* Features should not be backported to a `<major>.<minor>` branch.
* Bug fixes can be backported to a `<major>.<minor>` branch if the changes are safe and appropriate. Safety is a judgment call you make based on factors like the bug's severity, test coverage, confidence in the changes, etc. Your reasoning should be included in the pull request description.
* Documentation changes can be backported to any branch at any time.