Merge a52aab8598 into ee8b788538
This commit is contained in:
Bjorn Neergaard
GitHub
commit
60848f5598
3 changed files with 43 additions and 19 deletions
|
|
@ -1,32 +1,39 @@
|
|||
Branches and tags
|
||||
=================
|
||||
|
||||
Note: details of the release process for the Engine are documented in the
|
||||
[PATCH-RELEASES.md](https://github.com/moby/moby/blob/master/project/PATCH-RELEASES.md).
|
||||
> Note: details of the release process of the project are documented in [PATCH-RELEASES.md](PATCH-RELEASES.md).
|
||||
|
||||
# Branches
|
||||
|
||||
The docker/docker repository should normally have only three living branches at all time, including
|
||||
the regular `master` branch:
|
||||
`master` serves as the development branch for future releases of the project.
|
||||
All changes should be made to the `master` branch, and changes to release branches should only be made in the form of cherry-picked commits, if possible.
|
||||
The sponsoring maintainers of a release branch serve as the primary point of contact, and are available to provide guidance on contributing changes to their respective branches.
|
||||
|
||||
## `docs` branch
|
||||
Keep in mind that release branches only accept bug and security fixes; new features will generally not be considered for backport to release branches.
|
||||
|
||||
The `docs` branch supports documentation updates between product releases. This branch allow us to
|
||||
decouple documentation releases from product releases.
|
||||
Currently (and previously) maintained release branches are documented in the table below:
|
||||
|
||||
## `release` branch
|
||||
| Branch Name | Sponsoring Maintainer(s) | Contribution Status | Expected End of Maintenance | Known Distributors |
|
||||
|------------------------------------------------|------------------------------------------------|-----------------------|------------------------------|----------------------------------------------------------------------|
|
||||
| master (development branch) | The Moby Project [MAINTAINERS](../MAINTAINERS) | N/A | - | N/A |
|
||||
| 24.0 | @thaJeztah, @rumpl, @neersighted | Maintained | TBD | [Docker, Inc.](https://docker.com) |
|
||||
| 23.0 | @corhere, @cpuguy83 | Maintained | TBD | [Mirantis](https://mirantis.com), [Microsoft](https://microsoft.com) |
|
||||
| 20.10 | @corhere, @cpuguy83 | Maintained (security) | December 2023 | [Mirantis](https://mirantis.com), [Microsoft](https://microsoft.com) |
|
||||
|
||||
The `release` branch contains the last _released_ version of the code for the project.
|
||||
> Note: The Moby Project provides source code releases. Binary distributions are available from multiple contributing parties, and known distributions can be discovered in [PACKAGERS.md](PACKAGERS.md).
|
||||
|
||||
The `release` branch is only updated at each public release of the project. The mechanism for this
|
||||
is that the release is materialized by a pull request against the `release` branch which lives for
|
||||
the duration of the code freeze period. When this pull request is merged, the `release` branch gets
|
||||
updated, and its new state is tagged accordingly.
|
||||
## Contribution Status
|
||||
|
||||
The contribution status of a branch is meant to set contributor expectations for acceptance of changes into a branch, as well as document what level of contribution or maintenance the sponsoring maintainers expect to perform. This status is informational and not binding.
|
||||
|
||||
- **Maintained** - actively developed by project maintainers; accepting contributions and backports; in-scope for security advisories
|
||||
- **Maintained (security)** - no longer actively developed; may accept contributions and backports for critical security issues; in-scope for security advisories
|
||||
- **Unmaintained** - no longer actively developed; not accepting contributions; out-of-scope for security advisories
|
||||
|
||||
# Tags
|
||||
|
||||
Any public release of a compiled binary, with the logical exception of nightly builds, should have
|
||||
a corresponding tag in the repository.
|
||||
All releases of The Moby Project should have a corresponding tag in the repository.
|
||||
The project generally attempts to adhere to [Semantic Versioning](https://semver.org) whenever possible.
|
||||
|
||||
The general format of a tag is `vX.Y.Z[-suffix[N]]`:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,19 @@
|
|||
# Dear Packager,
|
||||
# For Users
|
||||
|
||||
The Moby Project is widely packaged by many independent software distributors,
|
||||
generally under the name 'docker' or 'docker.io.'
|
||||
|
||||
A non-exhuastive list of known software packagers and distributions includes:
|
||||
|
||||
- [Docker Inc. - Docker CE](https://docs.docker.com/engine/)
|
||||
- [Mirantis - Mirantis Container Runtime](https://docs.mirantis.com/mcr/)
|
||||
- [Microsoft - CBL-Mariner Linux](https://microsoft.github.io/CBL-Mariner/docs/)
|
||||
- [AWS - Amazon Linux](https://aws.amazon.com/linux/)
|
||||
|
||||
# For Packagers
|
||||
|
||||
If you are looking to make Docker available on your favorite software
|
||||
distribution, this document is for you. It summarizes the requirements for
|
||||
distribution, the following is for you. It summarizes the requirements for
|
||||
building and running the Docker client and the Docker daemon.
|
||||
|
||||
## Package Name
|
||||
|
|
@ -35,6 +47,10 @@ If you would rather (or must, due to distro policy) package these dependencies
|
|||
yourself, take a look at "vendor.mod" for an easy-to-parse list of the
|
||||
exact version for each.
|
||||
|
||||
Note that this project is **not** a Go module. To properly build the project,
|
||||
`GOPATH` mode must be used. The project is migrating to Go modules, but `vendor.mod`
|
||||
should not be interchanged with `go.mod` until this transition is complete.
|
||||
|
||||
## Stripping Binaries
|
||||
|
||||
Please, please, please do not strip any compiled binaries. This is really
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
// 'vendor.mod' enables use of 'go mod vendor' to managed 'vendor/' directory.
|
||||
// There is no 'go.mod' file, as that would imply opting in for all the rules
|
||||
// around SemVer, which this repo cannot abide by as it uses CalVer.
|
||||
// There is no 'go.mod' file, as the project has not yet completed the migration
|
||||
// to a Go module. This project should be built in GOPATH mode, and not module mode,
|
||||
// until the migration is complete and this file becomes 'go.mod.'
|
||||
|
||||
module github.com/docker/docker
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue