• Project scope
• Labels
  • Global
  • area/
  • exp/
  • impact/
  • kind/
  • needs/
  • priority/
  • status/
• Types of releases
  • Feature releases
    • Release Candidates
    • Support Policy
    • Contributing to Releases
  • Patch releases
• Milestones
• Triage process
  • Verify essential information
  • Classify the issue
• Prioritization guidelines for kind/bug
• Issue lifecyle
  • Examples
    • Submitting a bug
• Pull request review process
• Handling stalled issues and pull requests
• Moving to a discussion
• Workflow automation
  • Exempting an issue/PR from stale bot processing
• Updating dependencies

Docker Buildx is a Docker CLI plugin designed to extend build capabilities using BuildKit. It provides advanced features for building container images, supporting multiple builder instances, multi-node builds, and high-level build constructs. Buildx enhances the Docker build process, making it more efficient and flexible, and is compatible with both Docker and Kubernetes environments. Key features include:

• Familiar user experience: Buildx offers a user experience similar to legacy docker build, ensuring a smooth transition from legacy commands
• Full BuildKit capabilities: Leverage the full feature set of moby/buildkit when using the container driver
• Multiple builder instances: Supports the use of multiple builder instances, allowing concurrent builds and effective management and monitoring of these builders.
• Multi-node builds: Use multiple nodes to build cross-platform images
• Compose integration: Build complex, multi-services files as defined in compose
• High-level build constructs via bake: Introduces high-level build constructs for more complex build workflows
• In-container driver support: Support in-container drivers for both Docker and Kubernetes environments to support isolation/security.

Below are common groups, labels, and their intended usage to support issues, pull requests, and discussion processing.

General attributes that can apply to nearly any issue or pull request.

Area or component of the project affected. Please note that the table below may not be inclusive of all current options.

Estimated experience level to complete the item

Potential impact areas of the issue or pull request.

The type of issue, pull request or discussion

Actions or missing requirements needed by the issue or pull request.

Level of urgency of a kind/bug issue or pull request.

Current lifecycle state of the issue or pull request.

This project has feature releases, patch releases, and security releases.

Feature releases are made from the development branch, followed by cutting a release branch for future patch releases, which may also occur during the code freeze period.

Users can expect 2-3 release candidate (RC) test releases prior to a feature release. The first RC is typically released about one to two weeks before the final release.

Once a new feature release is cut, support for the previous feature release is discontinued. An exception may be made for urgent security releases that occur shortly after a new feature release. Buildx does not offer LTS (Long-Term Support) releases.

Anyone can request that an issue or PR be included in the next feature or patch release milestone, provided it meets the necessary requirements.

Patch releases should only include the most critical patches. Stability is vital, so everyone should always use the latest patch release.

If a fix is needed but does not qualify for a patch release because of its code size or other criteria that make it too unpredictable, we will prioritize cutting a new feature release sooner rather than making an exception for backporting.

Following PRs are included in patch releases

• priority/P0 fixes
• priority/P1 fixes, assuming maintainers don’t object because of the patch size
• priority/P2 fixes, only if (both required)
  • proposed by maintainer
  • the patch is trivial and self-contained
• Documentation-only patches
• Vendored dependency updates, only if:
  • Fixing (qualifying) bug or security issue in Buildx
  • The patch is small, else a forked version of the dependency with only the patches required

New features do not qualify for patch release.

Milestones are used to help identify what releases a contribution will be in.

• The v0.next milestone collects unblocked items planned for the next 2-3 feature releases but not yet assigned to a specific version milestone.
• The v0.backlog milestone gathers all triaged items considered for the long-term (beyond the next 3 feature releases) or currently unfit for a future release due to certain conditions. These items may be blocked and need to be unblocked before progressing.

Triage provides an important way to contribute to an open-source project. When submitted without an issue this process applies to Pull Requests as well. Triage helps ensure work items are resolved quickly by:

• Ensuring the issue's intent and purpose are described precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences a problem and what actions they took to arrive at the problem.
• Giving a contributor the information they need before they commit to resolving an issue.
• Lowering the issue count by preventing duplicate issues.
• Streamlining the development process by preventing duplicate discussions.

If you don't have time to code, consider helping with triage. The community will thank you for saving them time by spending some of yours. The same basic process should be applied upon receipt of a new issue.

1. Verify essential information
2. Classify the issue
3. Prioritizing the issue

Before advancing the triage process, ensure the issue contains all necessary information to be properly understood and assessed. The required information may vary by issue type, but typically includes the system environment, version numbers, reproduction steps, expected outcomes, and actual results.

• Exercising Judgment: Use your best judgment to assess the issue description’s completeness.
• Communicating Needs: If the information provided is insufficient, kindly request additional details from the author. Explain that this information is crucial for clarity and resolution of the issue, and apply the needs/more-information label to indicate a response from the author is required.

An issue will typically have multiple labels. These are used to help communicate key information about context, requirements, and status. At a minimum, a properly classified issue should have:

• (Required) One or more area/* labels
• (Required) One kind/* label to indicate the type of issue
• (Required if kind/bug) A priority/* label

When assigning a decision the following labels should be present:

• (Required) One status/* label to indicate lifecycle status

Additional labels can provide more clarity:

• Zero or more needs/* labels to indicate missing items
• Zero or more impact/* labels
• One exp/* label

When an issue or pull request of kind/bug is correctly categorized and attached to a milestone, the labels indicate the urgency with which it should be completed.

priority/P0

Fixing this item is the highest priority. A patch release will follow as soon as a patch is available and verified. This level is used exclusively for bugs.

Examples:

• Regression in a critical code path
• Panic in a critical code path
• Corruption in critical code path or rest of the system
• Leaked zero-day critical security

priority/P1

Items with this label should be fixed with high priority and almost always included in a patch release. Unless waiting for another issue, patch releases should happen within a week. This level is not used for features or enhancements.

Examples:

• Any regression, panic
• Measurable performance regression
• A major bug in a new feature in the latest release
• Incompatibility with upgraded external dependency

priority/P2

This is the default priority and is implied in the absence of a priority/ label. Bugs with this priority should be included in the next feature release but may land in a patch release if they are ready and unlikely to impact other functionality adversely. Non-bug issues with this priority should also be included in the next feature release if they are available and ready.

Examples:

• Confirmed bugs
• Bugs in non-default configurations
• Most enhancements

flowchart LR
  create([New issue]) --> triage
  subgraph triage[Triage Loop]
    review[Review]
  end
  subgraph decision[Decision]
    accept[Accept]
    close[Close]
  end
  triage -- if accepted --> accept[Assign status, milestone]
  triage -- if rejected --> close[Assign status, close issue]

To help illustrate the issue life cycle let’s walk through submitting an issue as a potential bug in CI that enters a feedback loop and is eventually accepted as P2 priority and placed on the backlog.

flowchart LR

	new([New issue])
	
	subgraph triage[Triage]
	direction LR
	
  create["Action: Submit issue via Bug form\nLabels: kind/maybe-bug, status/triage"]
  style create text-align:left

		subgraph review[Review]
		direction TB
	  classify["Action: Maintainer reviews issue, requests more info\nLabels: kind/maybe-bug, status/triage, needs/more-info, area/*"]
	  style classify text-align:left
	  
	  update["Action: Author updates issue\nLabels: kind/maybe-bug, status/triage, needs/more-info, area/*"]
	  style update text-align:left
	
	  classify --> update
	  update --> classify
	  end
  
  create --> review
  end

	subgraph decision[Decision]
	accept["Action: Maintainer reviews updates, accepts, assigns milestone\nLabels: kind/bug, priority/P2, status/accepted, area/*, impact/*"]
  style accept text-align: left
  end
  
  new --> triage
  triage --> decision

A thorough and timely review process for pull requests (PRs) is crucial for maintaining the integrity and quality of the project while fostering a collaborative environment.

• Labeling: Most labels should be inherited from a linked issue. If no issue is linked an extended review process may be required.
• Continuous Integration: With few exceptions, it is crucial that all Continuous Integration (CI) workflows pass successfully.
• Draft Status: Incomplete or long-running PRs should be placed in "Draft" status. They may revert to "Draft" status upon initial review if significant rework is required.

flowchart LR
  triage([Triage])
  draft[Draft PR]
  review[PR Review]
  closed{{Close PR}}
  merge{{Merge PR}}

  subgraph feedback1[Feedback Loop]
    draft
  end
  subgraph feedback2[Feedback Loop]
     review
  end

  triage --> draft
  draft --> review
  review --> closed
  review --> draft
  review --> merge

Unfortunately, some issues or pull requests can remain inactive for extended periods. To mitigate this, automation is employed to prompt both the author and maintainers, ensuring that all contributions receive appropriate attention.

For Authors:

• Closure of Inactive Items: If your issue or PR becomes irrelevant or is no longer needed, please close it to help keep the project clean.
• Prompt Responses: If additional information is requested, please respond promptly to facilitate progress.

For Maintainers:

• Timely Responses: Endeavor to address issues and PRs within a reasonable timeframe to keep the community actively engaged.
• Engagement with Stale Issues: If an issue becomes stale due to maintainer inaction, re-engage with the author to reassess and revitalize the discussion.

Stale and Rotten Policy:

• An issue or PR will be labeled as stale after 14 calendar days of inactivity. If it remains inactive for another 30 days, it will be labeled as rotten and closed.
• Authors whose issues or PRs have been closed are welcome to re-open them or create new ones and link to the original.

Skipping Stale Processing:

• To prevent an issue or PR from being marked as stale, label it as frozen.

Exceptions to Stale Processing:

• Issues or PRs marked as frozen.
• Issues or PRs assigned to a milestone.

Sometimes, an issue or pull request may not be the appropriate medium for what is essentially a discussion. In such cases, the issue or PR will either be converted to a discussion or a new discussion will be created. The original item will then be labeled appropriately (kind/discussion or kind/question) and closed.

If you believe this conversion was made in error, please express your concerns in the new discussion thread. If necessary, a reversal to the original issue or PR format can be facilitated.

To help expedite common operations, avoid errors and reduce toil some workflow automation is used by the project. This can include:

• Stale issue or pull request processing
• Auto-labeling actions
• Auto-response actions
• Label carry over from issue to pull request

The stale item handling is configured in the repository. To exempt an issue or PR from stale processing you can:

• Add the item to a milestone
• Add the frozen label to the item

• Runtime Dependencies: Use the latest stable release available when the first Release Candidate (RC) of a new feature release is cut. For patch releases, update to the latest corresponding patch release of the dependency.
• Other Dependencies: Always permitted to update to the latest patch release in the development branch. Updates to a new feature release require justification, unless the dependency is outdated. Prefer tagged versions of dependencies unless a specific untagged commit is needed. Go modules should specify the lowest compatible version; there is no requirement to update all dependencies to their latest versions before cutting a new Buildx feature release.
• Patch Releases: Vendored dependency updates are considered for patch releases, except in the rare cases specified previously.
• Security Considerations: A security scanner report indicating a non-exploitable issue via Buildx does not justify backports.