Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of. It is also worth asking on the Slack channels.
Before opening a new issue or submitting a new pull request, it's helpful to search the project -
it's likely that another user has already reported the issue you're facing, or it's a known issue
that we're already aware of. It is also worth asking on the Slack channels.
## Milestones
## Milestones
We use milestones to track progress of releases. There are also 2 special milestones
We use milestones to track progress of releases. There are also 2 special milestones used for
used for helping us keep work organized: `Upcoming - Minor` and `Upcoming - Major`
helping us keep work organized: `Upcoming - Minor` and `Upcoming - Major`
`Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific
`Upcoming - Minor` is used for keeping track of issues that aren't assigned to a specific release
release but could easily be addressed in a minor release. `Upcoming - Major` keeps track
but could easily be addressed in a minor release. `Upcoming - Major` keeps track of issues that will
of issues that will need to be addressed in a major release. For example, if the current
need to be addressed in a major release. For example, if the current version is `3.2.0` an issue/PR
version is `3.2.0` an issue/PR could fall in to one of 4 different active milestones:
could fall in to one of 4 different active milestones:`3.2.1`, `3.3.0`, `Upcoming - Minor`, or
`3.2.1`, `3.3.0`, `Upcoming - Minor`, or `Upcoming - Major`. If an issue pertains to a
`Upcoming - Major`. If an issue pertains to a specific upcoming bug or minor release, it would go
specific upcoming bug or minor release, it would go into `3.2.1` or `3.3.0`. If the issue/PR
into `3.2.1` or `3.3.0`. If the issue/PR does not have a specific milestone yet, but it is likely
does not have a specific milestone yet, but it is likely that it will land in a `3.X` release,
that it will land in a `3.X` release, it should go into `Upcoming - Minor`. If the issue/PR is a
it should go into `Upcoming - Minor`. If the issue/PR is a large functionality add or change
large functionality add or change and/or it breaks compatibility, then it should be added to the
and/or it breaks compatibility, then it should be added to the `Upcoming - Major` milestone.
`Upcoming - Major` milestone. An issue that we are not sure we will be doing will not be added to
An issue that we are not sure we will be doing will not be added to any milestone.
any milestone.
A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed or moved to another milestone.
A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed
or moved to another milestone.
## Semantic Versioning
## Semantic Versioning
Helm maintains a strong commitment to backward compatibility. All of our changes to protocols and formats are backward compatible from one major release to the next. No features, flags, or commands are removed or substantially modified (unless we need to fix a security issue).
Helm maintains a strong commitment to backward compatibility. All of our changes to protocols and
formats are backward compatible from one major release to the next. No features, flags, or commands
are removed or substantially modified (unless we need to fix a security issue).
We also try very hard to not change publicly accessible Go library definitions inside of the `pkg/` directory of our source code.
We also try very hard to not change publicly accessible Go library definitions inside of the `pkg/`
directory of our source code.
For a quick summary of our backward compatibility guidelines for releases between 3.0 and 4.0:
For a quick summary of our backward compatibility guidelines for releases between 3.0 and 4.0:
- Command line commands, flags, and arguments MUST be backward compatible
- Command line commands, flags, and arguments MUST be backward compatible
- File formats (such as Chart.yaml) MUST be backward compatible
- File formats (such as Chart.yaml) MUST be backward compatible
- Any chart that worked on a previous version of Helm 3 MUST work on a new version of Helm 3 (barring the cases where (a) Kubernetes itself changed, and (b) the chart worked because it exploited a bug)
- Any chart that worked on a previous version of Helm 3 MUST work on a new version of Helm 3
(barring the cases where (a) Kubernetes itself changed, and (b) the chart worked because it
exploited a bug)
- Chart repository functionality MUST be backward compatible
- Chart repository functionality MUST be backward compatible
- Go libraries inside of `pkg/` SHOULD remain backward compatible, though code inside of `cmd/` and `internal/` may be changed from release to release without notice.
- Go libraries inside of `pkg/` SHOULD remain backward compatible, though code inside of `cmd/` and
`internal/` may be changed from release to release without notice.
## Support Contract for Helm 2
## Support Contract for Helm 2
With Helm 2's current release schedule, we want to take into account any migration issues for users due to the upcoming holiday shopping season and tax season. We also want to clarify what actions may occur after the support contract ends for Helm 2, so that users will not be surprised or caught off guard.
With Helm 2's current release schedule, we want to take into account any migration issues for users
due to the upcoming holiday shopping season and tax season. We also want to clarify what actions may
occur after the support contract ends for Helm 2, so that users will not be surprised or caught off
guard.
After Helm 2.15.0 is released, Helm 2 will go into "maintenance mode". We will continue to accept bug fixes and fix any security issues that arise, but no new features will be accepted for Helm 2. All feature development will be moved over to Helm 3.
After Helm 2.15.0 is released, Helm 2 will go into "maintenance mode". We will continue to accept
bug fixes and fix any security issues that arise, but no new features will be accepted for Helm 2.
All feature development will be moved over to Helm 3.
6 months after Helm 3.0.0's public release, Helm 2 will stop accepting bug fixes. Only security issues will be accepted.
6 months after Helm 3.0.0's public release, Helm 2 will stop accepting bug fixes. Only security
issues will be accepted.
12 months after Helm 3.0.0's public release, support for Helm 2 will formally end. Download links for the Helm 2 client through Google Cloud Storage, the Docker image for Tiller stored in Google Container Registry, and the Google Cloud buckets for the stable and incubator chart repositories may no longer work at any point. Client downloads through `get.helm.sh` will continue to work, and we will distribute a Tiller image that will be made available at an alternative location which can be updated with `helm init --tiller-image`.
12 months after Helm 3.0.0's public release, support for Helm 2 will formally end. Download links
for the Helm 2 client through Google Cloud Storage, the Docker image for Tiller stored in Google
Container Registry, and the Google Cloud buckets for the stable and incubator chart repositories may
no longer work at any point. Client downloads through `get.helm.sh` will continue to work, and we
will distribute a Tiller image that will be made available at an alternative location which can be
updated with `helm init --tiller-image`.
## Issues
## Issues
@ -141,45 +162,46 @@ Issues are used as the primary method for tracking anything to do with the Helm
There are 5 types of issues (each with their own corresponding [label](#labels)):
There are 5 types of issues (each with their own corresponding [label](#labels)):
- `question/support`: These are support or functionality inquiries that we want to have a record of for
- `question/support`: These are support or functionality inquiries that we want to have a record of
future reference. Generally these are questions that are too complex or large to store in the
for future reference. Generally these are questions that are too complex or large to store in the
Slack channel or have particular interest to the community as a whole. Depending on the discussion,
Slack channel or have particular interest to the community as a whole. Depending on the
these can turn into `feature` or `bug` issues.
discussion, these can turn into `feature` or `bug` issues.
- `proposal`: Used for items (like this one) that propose a new ideas or functionality that require
- `proposal`: Used for items (like this one) that propose a new ideas or functionality that require
a larger community discussion. This allows for feedback from others in the community before a
a larger community discussion. This allows for feedback from others in the community before a
feature is actually developed. This is not needed for small additions. Final word on whether or
feature is actually developed. This is not needed for small additions. Final word on whether or
not a feature needs a proposal is up to the core maintainers. All issues that are proposals should
not a feature needs a proposal is up to the core maintainers. All issues that are proposals should
both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become
both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become
a `feature` and does not require a milestone.
a `feature` and does not require a milestone.
- `feature`: These track specific feature requests and ideas until they are complete. They can evolve
- `feature`: These track specific feature requests and ideas until they are complete. They can
from a `proposal` or can be submitted individually depending on the size.
evolve from a `proposal` or can be submitted individually depending on the size.
- `bug`: These track bugs with the code
- `bug`: These track bugs with the code
- `docs`: These track problems with the documentation (i.e. missing or incomplete)
- `docs`: These track problems with the documentation (i.e. missing or incomplete)
### Issue Lifecycle
### Issue Lifecycle
The issue lifecycle is mainly driven by the core maintainers, but is good information for those
The issue lifecycle is mainly driven by the core maintainers, but is good information for those
contributing to Helm. All issue types follow the same general lifecycle. Differences are noted below.
contributing to Helm. All issue types follow the same general lifecycle. Differences are noted
below.
1. Issue creation
1. Issue creation
2. Triage
2. Triage
- The maintainer in charge of triaging will apply the proper labels for the issue. This
- The maintainer in charge of triaging will apply the proper labels for the issue. This includes
includes labels for priority, type, and metadata (such as `good first issue`). The only issue
labels for priority, type, and metadata (such as `good first issue`). The only issue priority
priority we will be tracking is whether or not the issue is "critical." If additional
we will be tracking is whether or not the issue is "critical." If additional levels are needed
levelsare needed in the future, we will add them.
in the future, we will add them.
- (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure
- (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that
that proposals are prefaced with "Proposal: [the rest of the title]".
proposals are prefaced with "Proposal: [the rest of the title]".
- Add the issue to the correct milestone. If any questions come up, don't worry about
- Add the issue to the correct milestone. If any questions come up, don't worry about adding the
addingthe issue to a milestone until the questions are answered.
issue to a milestone until the questions are answered.
- We attempt to do this process at least once per work day.
- We attempt to do this process at least once per work day.
3. Discussion
3. Discussion
- issues that are labeled as `feature` or `bug` should be connected to the PR that resolves it.
- issues that are labeled as `feature` or `bug` should be connected to the PR that resolves it.
- Whoever is working on a `feature` or `bug` issue (whether a maintainer or someone from
- Whoever is working on a `feature` or `bug` issue (whether a maintainer or someone from the
the community), should either assign the issue to themself or make a comment in the issue
community), should either assign the issue to themself or make a comment in the issue saying
saying that they are taking it.
that they are taking it.
- `proposal` and `support/question` issues should stay open until resolved or if they have not been
- `proposal` and `support/question` issues should stay open until resolved or if they have not
active for more than 30 days. This will help keep the issue queue to a manageable size and
been active for more than 30 days. This will help keep the issue queue to a manageable size
reduce noise. Should the issue need to stay open, the `keep open` label can be added.
and reduce noise. Should the issue need to stay open, the `keep open` label can be added.
4. Issue closure
4. Issue closure
## How to Contribute a Patch
## How to Contribute a Patch
@ -188,7 +210,8 @@ contributing to Helm. All issue types follow the same general lifecycle. Differe
2. Fork the desired repo; develop and test your code changes.
2. Fork the desired repo; develop and test your code changes.
3. Submit a pull request, making sure to sign your work and link the related issue.
3. Submit a pull request, making sure to sign your work and link the related issue.
Coding conventions and standards are explained in the [official developer docs](https://helm.sh/docs/developers/).
Coding conventions and standards are explained in the [official developer
docs](https://helm.sh/docs/developers/).
## Pull Requests
## Pull Requests
@ -199,41 +222,42 @@ Like any good open source project, we use Pull Requests (PRs) to track code chan
1. PR creation
1. PR creation
- PRs are usually created to fix or else be a subset of other PRs that fix a particular issue.
- PRs are usually created to fix or else be a subset of other PRs that fix a particular issue.
- We more than welcome PRs that are currently in progress. They are a great way to keep track of
- We more than welcome PRs that are currently in progress. They are a great way to keep track of
important work that is in-flight, but useful for others to see. If a PR is a work in progress,
important work that is in-flight, but useful for others to see. If a PR is a work in progress,
it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP" from
it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP"
the title.
from the title.
- It is preferred, but not required, to have a PR tied to a specific issue. There can be
- It is preferred, but not required, to have a PR tied to a specific issue. There can be
circumstances where if it is a quick fix then an issue might be overkill. The details provided
circumstances where if it is a quick fix then an issue might be overkill. The details provided
in the PR description would suffice in this case.
in the PR description would suffice in this case.
2. Triage
2. Triage
- The maintainer in charge of triaging will apply the proper labels for the issue. This should
- The maintainer in charge of triaging will apply the proper labels for the issue. This should
include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied.
include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are
See the [Labels section](#labels) for full details on the definitions of labels.
applied. See the [Labels section](#labels) for full details on the definitions of labels.
- Add the PR to the correct milestone. This should be the same as the issue the PR closes.
- Add the PR to the correct milestone. This should be the same as the issue the PR closes.
3. Assigning reviews
3. Assigning reviews
- Once a review has the `awaiting review` label, maintainers will review them as schedule permits.
- Once a review has the `awaiting review` label, maintainers will review them as schedule
The maintainer who takes the issue should self-request a review.
permits. The maintainer who takes the issue should self-request a review.
- Any PR with the `size/large` label requires 2 review approvals from maintainers before it can be
- Any PR with the `size/large` label requires 2 review approvals from maintainers before it can
merged. Those with `size/medium` or `size/small` are per the judgement of the maintainers.
be merged. Those with `size/medium` or `size/small` are per the judgement of the maintainers.
4. Reviewing/Discussion
4. Reviewing/Discussion
- All reviews will be completed using Github review tool.
- All reviews will be completed using Github review tool.
- A "Comment" review should be used when there are questions about the code that should be
- A "Comment" review should be used when there are questions about the code that should be
answered, but that don't involve code changes. This type of review does not count as approval.
answered, but that don't involve code changes. This type of review does not count as approval.
- A "Changes Requested" review indicates that changes to the code need to be made before they will be merged.
- A "Changes Requested" review indicates that changes to the code need to be made before they
will be merged.
- Reviewers should update labels as needed (such as `needs rebase`)
- Reviewers should update labels as needed (such as `needs rebase`)
5. Address comments by answering questions or changing code
5. Address comments by answering questions or changing code
6. LGTM (Looks good to me)
6. LGTM (Looks good to me)
- Once a Reviewer has completed a review and the code looks ready to merge, an "Approve" review is used
- Once a Reviewer has completed a review and the code looks ready to merge, an "Approve" review
to signal to the contributor and to other maintainers that you have reviewed the code and feel that it is
is used to signal to the contributor and to other maintainers that you have reviewed the code
ready to be merged.
and feel that it is ready to be merged.
7. Merge or close
7. Merge or close
- PRs should stay open until merged or if they have not been active for more than 30 days.
- PRs should stay open until merged or if they have not been active for more than 30 days. This
This will help keep the PR queue to a manageable size and reduce noise. Should the PR need
will help keep the PR queue to a manageable size and reduce noise. Should the PR need to stay
tostay open (like in the case of a WIP), the `keep open` label can be added.
open (like in the case of a WIP), the `keep open` label can be added.
- Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if
- Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if
the PR requires more than one LGTM to merge.
the PR requires more than one LGTM to merge.
- If the owner of the PR is listed in the `OWNERS` file, that user **must** merge their own PRs
- If the owner of the PR is listed in the `OWNERS` file, that user **must** merge their own PRs
or explicitly request another OWNER do that for them.
or explicitly request another OWNER do that for them.
- If the owner of a PR is _not_ listed in `OWNERS`, any core maintainer may merge the PR.
- If the owner of a PR is _not_ listed in `OWNERS`, any core maintainer may merge the PR.
#### Documentation PRs
#### Documentation PRs
@ -286,12 +310,12 @@ The following tables define all label types used for Helm. It is split up by cat
#### Size labels
#### Size labels
Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the
Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign
labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes
the labels, but ultimately this can be changed by the maintainers. For example, even if a PR only
30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as`size/L`
makes 30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as
because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires
`size/L`because it requires sign off from multiple people. Conversely, a PR that adds a small
another 150 lines of tests to cover all cases, could be labeled as `size/S` even though the number of
feature, but requires another 150 lines of tests to cover all cases, could be labeled as `size/S`
lines is greater than defined below.
even though the number of lines is greater than defined below.
PRs submitted by a core maintainer, regardless of size, only requires approval from one additional
PRs submitted by a core maintainer, regardless of size, only requires approval from one additional
maintainer. This ensures there are at least two maintainers who are aware of any significant PRs
maintainer. This ensures there are at least two maintainers who are aware of any significant PRs
Matthew Fisher
5 years ago