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
The following is a living issue, pinned to the top of domicile GitHub issues for wide visibility, that represents the current labeling, triaging, milestone, and maintenance state of domicile. Maintainers, contributors, and users may refer to this in order to understand how bugs and features are being triaged and where their feature request may be in the maintenance cycle.
kind/bug: A bug in domicile; unintended behavior
kind/feature: A feature request for domicile; new or enhanced behavior
kind/docs: Documentation
kind/testing: CI/CD, testing, etc. for domicile. Usually also gets the github label
kind/security: Related to security concerns in domicile itself. Refer to the security policy before opening any public issue.
kind/deprecation: Related to a feature or part of code being deprecated
kind/support: Questions, supporting users, etc.
area/ - The area of work that needs to be executed against
area/github: For changes to Github specific things not shipped in the app (like maintainers files, actions, etc)
triage/ - The state of an issue being triaged
triage/needs-triage: Needs to be placed into a milestone or be closed by maintainers. This label is removed once placed into a milestone.
triage/blocked: Cannot move forward until some roadblock is lifted
triage/needs-info: An issue that needs more investigation from maintainers or more info from the issue provider
triage/duplicate: A duplicate issue. These issues are usually closed after receiving this label.
lifecycle/ - Where something is at in its lifecycle
lifecycle/active: Actively being worked on by a community member or maintainer. This label should also correspond with someone being assigned to the issue
lifecycle/needs-proposal: For large features / bugs that need a proposal and community buy in
lifecycle/approved: For large features / bugs that have a proposal and have gotten community buy in
lifecycle/needs-pr: Ready for a PR from the community
lifecycle/stale: Labeled by GitHub actions after 30 days of inactivity
lifecycle/rotten: Labeled by GitHub actions after 30 days of having the lifecycle/stale label. Issues and PRs with this label will close after another 30 days of inactivity.
lifecycle/frozen: Prevents GitHub actions from labeling Issues and PRs with lifecycle/stale or lifecycle/rotten
`lifecycle/rejected: For issues and PRs the community has determined are not a priority and will not execute against
size/ - The size of the PR
Utilizes the pr-size-labeler to label PRs with a given size per number of lines changed
size/xs: Denotes a PR that changes 0-9 lines
size/s: Denotes a PR that changes 10-24 lines
size/m: Denotes a PR that changes 24-99 lines
size/l: Denotes a PR that changes 100-199 lines
size/xl: Denotes a PR that changes 200 or more lines. Note: An XL pull request exceeds the recommended size of changes in a single PR. This is fine, but needs special attention from maintainers and may be rejected due to it's size. Make sure you are not addressing multiple issues in a single PR.
Milestones
Milestones are used to categorize work and contributions into specific releases.
The next milestone is used as a catch all for work that is being planned for some arbitrary upcoming release by the community
The icebox milestone is used to track things that may need to be executed against eventually but are blocked, have the lifecycle/frozen label, etc.
Release cadence
domicile attempts to release quarterly. This is a best effort.
Generally, a pinned release tracker issue is made that corresponds with the current release. On release, tags will be made on GitHub that then can be consumed by downstream Go modules.
major bumps (i.e. v1.x.x to v2.x.x) have breaking changes (like deprecations, changing APIs, etc).
minor bumps (i.e v1.1.x to 1.2.x) have no breaking changes, but include new features.
patch bumps (i.e. v1.1.1 to v1.1.2) do not include new features or breaking changes but only backwards compatible bug fixes.
The text was updated successfully, but these errors were encountered:
Labels, Milestones, and Triaging
The following is a living issue, pinned to the top of domicile GitHub issues for wide visibility, that represents the current labeling, triaging, milestone, and maintenance state of domicile. Maintainers, contributors, and users may refer to this in order to understand how bugs and features are being triaged and where their feature request may be in the maintenance cycle.
Inspired by cobra
Labels
kind/ - The type of issue
kind/bug
: A bug in domicile; unintended behaviorkind/feature
: A feature request for domicile; new or enhanced behaviorkind/docs
: Documentationkind/testing
: CI/CD, testing, etc. for domicile. Usually also gets the github labelkind/security
: Related to security concerns in domicile itself. Refer to the security policy before opening any public issue.kind/deprecation
: Related to a feature or part of code being deprecatedkind/support
: Questions, supporting users, etc.area/ - The area of work that needs to be executed against
area/github
: For changes to Github specific things not shipped in the app (like maintainers files, actions, etc)triage/ - The state of an issue being triaged
triage/needs-triage
: Needs to be placed into a milestone or be closed by maintainers. This label is removed once placed into a milestone.triage/blocked
: Cannot move forward until some roadblock is liftedtriage/needs-info
: An issue that needs more investigation from maintainers or more info from the issue providertriage/duplicate
: A duplicate issue. These issues are usually closed after receiving this label.lifecycle/ - Where something is at in its lifecycle
lifecycle/active
: Actively being worked on by a community member or maintainer. This label should also correspond with someone being assigned to the issuelifecycle/needs-proposal
: For large features / bugs that need a proposal and community buy inlifecycle/approved
: For large features / bugs that have a proposal and have gotten community buy inlifecycle/needs-pr
: Ready for a PR from the communitylifecycle/stale
: Labeled by GitHub actions after 30 days of inactivitylifecycle/rotten
: Labeled by GitHub actions after 30 days of having the lifecycle/stale label. Issues and PRs with this label will close after another 30 days of inactivity.lifecycle/frozen
: Prevents GitHub actions from labeling Issues and PRs with lifecycle/stale or lifecycle/rotten `lifecycle/rejected: For issues and PRs the community has determined are not a priority and will not execute againstsize/ - The size of the PR Utilizes the pr-size-labeler to label PRs with a given size per number of lines changed
size/xs
: Denotes a PR that changes 0-9 linessize/s
: Denotes a PR that changes 10-24 linessize/m
: Denotes a PR that changes 24-99 linessize/l
: Denotes a PR that changes 100-199 linessize/xl
: Denotes a PR that changes 200 or more lines. Note: An XL pull request exceeds the recommended size of changes in a single PR. This is fine, but needs special attention from maintainers and may be rejected due to it's size. Make sure you are not addressing multiple issues in a single PR.Milestones
Milestones are used to categorize work and contributions into specific releases.
The next milestone is used as a catch all for work that is being planned for some arbitrary upcoming release by the community The icebox milestone is used to track things that may need to be executed against eventually but are blocked, have the lifecycle/frozen label, etc.
Release cadence
domicile attempts to release quarterly. This is a best effort.
Generally, a pinned release tracker issue is made that corresponds with the current release. On release, tags will be made on GitHub that then can be consumed by downstream Go modules.
SemVer
domicile follows Semantic Versioning. This generally means that:
major bumps (i.e. v1.x.x to v2.x.x) have breaking changes (like deprecations, changing APIs, etc). minor bumps (i.e v1.1.x to 1.2.x) have no breaking changes, but include new features. patch bumps (i.e. v1.1.1 to v1.1.2) do not include new features or breaking changes but only backwards compatible bug fixes.
The text was updated successfully, but these errors were encountered: