Merge branch 'main' into buildpack/0.7

CONTRIBUTING.md

@@ -0,0 +1,13 @@
+## Contributing to a Release
+
+Contributions should generally adhere to the following guidelines:
+
+1. Contributions should always be made to a release branch and never to the `main` branch, except when modifying [`README.md`](README.md) or files which are not formally part of the specification such as this one ([`RELEASE.md`](RELEASE.md)).
+1. Other than the first commit (which bumps the specification version in `README.md`), all PRs to a given release branch should only modify the named specification (e.g. PRS to `buildpack/0.5` should exclusively modify [`buildpack.md`](buildpack.md)). If a contributor wishes to modify two specification files (for example to move contend from `buildpack.md` to `platform.md`) two PRs should be opened against the release branches for the respective specifications.
+1. A PR should either:
+   1. Implement an issue that has been scheduled in an upcoming milestone, in which case it should point at the branch that matches the milestone.
+   1. Make a non-functional typographical or organizational improvement, in which case it should point at the branch for the next release of the given specification.
+1. Please do not open a PR implementing an issue that is not yet associated milestone. Instead, please comment on the issue and work with the core team to get it scheduled.
+1. Please do not propose major changes to the specification exclusively via a PR to this repo. Instead, please propose an [RFC](https://github.com/buildpacks/rfcs) or provide feedback via an issue so that it may eventually be addressed in an RFC. However, a draft PR may accompany/clarify an RFC.
+
+See [`RELEASE.md`](./RELEASE.md) for more details on the release process.

README.md

@@ -51,5 +51,5 @@ When the specification refers to a path in the context of an OCI layer tar (e.g.
 These documents currently specify:
 
 - Buildpack API: `0.7`
-- Distribution API: `0.2`
-- Platform API: `0.6`
+- Distribution API: `0.3`
+- Platform API: `0.8`

RELEASE.md

@@ -0,0 +1,42 @@
+# Release Process
+
+## Scaffolding a New Release
+
+When planning a spec release a maintainer should:
+1. Create a milestone for the release (e.g. [`Buildpack 0.5`](https://github.com/buildpacks/spec/milestone/9))
+1. Create a release branch from `main` branch with name `<spec>/<version>` (e.g. `buildpack/0.5`) or `extensions/<spec>/version>` for extension specifications.
+1. Update the version of the relevant spec in `README.md` and the specification file (e.g. see commit [791363e](https://github.com/buildpacks/spec/commit/791363e329d22a7a116ac09df6e8c739ef21383e)).
+1. Push the branch to the repo.
+
+
+## Release Planning
+
+Issues that are scheduled for a given release should be added to the milestone. The core team will regularly review and adjust the contents of upcoming milestones at the weekly [core team sync](https://github.com/buildpacks/community#core-team).
+
+## Accepting Contributions to a Release
+When a PR is opened, the first core team member to review should:
+1. Convert to draft if the PR implements an issue that has not been scheduled in a milestone.
+1. Ensure the PR is pointed at the correct branch.
+1. Request changes if the PR modifies any of the other specifications.
+1. Add the PR to a milestone, if this was not done already.
+1. Add the matching `api/*` label if this was not done already (e.g. [api/buildpack](https://github.com/buildpacks/spec/pulls?q=is%3Apr+label%3Aapi%2Fbuildpack+is%3Aopen) )
+
+Spec changes must be approved by a super-majority of the core team.
+
+## Finalizing the Release
+When all issues and PRs in a given milestone are complete, a core team member may:
+1. Create a PR to "finalize" the release, merge the release branch to `main`.
+1. Create a draft release and write release notes.
+
+## Approving the Final Release
+All core team members and any interested maintainers should:
+1. Review the release in its entirety and provide last minute feedback as needed.
+1. Review the release notes if they desire.
+1. Approve the final PR.
+
+## Cutting the Release
+Once the final PR has the required approvals, the person that opened it should:
+1. Merge the PR.
+1. Publish the release.
+1. Close the milestone.
+1. Delete the release branch.

distribution.md

@@ -15,7 +15,7 @@ This document specifies the artifact format, delivery mechanism, and order resol
 
 ## Distribution API Version
 
-This document specifies Distribution API version `0.2`.
+This document specifies Distribution API version `0.3`.
 
 Distribution API versions:
  - MUST be in form `<major>.<minor>` or `<major>`, where `<major>` is equivalent to `<major>.0`