Add ROADMAP.md to the project and cleanup existing items

Signed-off-by: Stephen J Day <stephen.day@docker.com>
This commit is contained in:
Stephen J Day 2015-03-17 22:02:11 -07:00
parent ac550484be
commit 574c9c821b
5 changed files with 96 additions and 113 deletions

View File

@ -60,6 +60,8 @@ The new registry implementation provides the following benefits:
- pluggable storage backend
- webhook notifications
For information on upcoming functionality, please see [ROADMAP.md](ROADMAP.md).
Installation
------------

94
ROADMAP.md Normal file
View File

@ -0,0 +1,94 @@
# Roadmap
This document covers the high-level the goals and dates for features in the
docker registry. The distribution project currently has several components to
report in the road map, which are covered below.
## Goals
- Replace the existing [docker registry](github.com/docker/docker-registry)
implementation as the primary implementation.
- Replace the existing push and pull code in the docker engine with the
distribution package.
- Define a strong data model for distributing docker images
- Provide a flexible distribution tool kit for use in the docker platform
## Components
The distribution project has a few components with independent road maps and
road maps related to the docker project. They are covered below.
### Registry
The current status of the registry road map is managed via github
[milestones](https://github.com/docker/distribution/milestones). Upcoming
features and bugfixes will be added to relevant milestones. If a feature or
bugfix is not part of a milestone, it is currently unscheduled for
implementation.
The high-level goals for each registry release are part of this section.
#### 2.0
Milestones: [2.0.0-beta](https://github.com/docker/distribution/milestones/Registry/2.0.0-beta) [2.0.0-rc](https://github.com/docker/distribution/milestones/Registry/2.0.0-rc) [2.0.0](https://github.com/docker/distribution/milestones/Registry/2.0.0)
The 2.0 release is the first release of the new registry. This is mostly
focused on implementing the [new registry
API](https://github.com/docker/distribution/blob/master/doc/spec/api.md) with
a focus on security and performance.
Features:
- Faster push and pull
- New, more efficient implementation
- Simplified deployment
- Full API specification for V2 protocol
- Pluggable storage system (s3, azure, filesystem and inmemory supported)
- Immutable manifest references ([#46](https://github.com/docker/distribution/issues/46))
- Webhook notification system ([#42](https://github.com/docker/distribution/issues/42))
- Native TLS Support ([#132](https://github.com/docker/distribution/pull/132))
- Pluggable authentication system
- Health Checks ([#230](https://github.com/docker/distribution/pull/230))
#### 2.1
Milestone: [2.1](https://github.com/docker/distribution/milestones/Registry/2.1)
Planned Features:
> **NOTE:** This feature list is incomplete at this time.
- Support for Manifest V2, Schema 2 and explicit tagging objects ([#62](https://github.com/docker/distribution/issues/62), [#173](https://github.com/docker/distribution/issues/173))
- Mirroring ([#19](https://github.com/docker/distribution/issues/19))
- Flexible client package based on distribution interfaces ([#193](https://github.com/docker/distribution/issues/193)
#### 2.2
Milestone: [2.2](https://github.com/docker/distribution/milestones/Registry/2.2)
TBD
### Docker Platform
To track various requirements that must be synced with releases of the docker
platform, we've defined labels corresponding to upcoming releases. Each
release also has a project page explaining the relationship of the
distribution project with the docker project.
Please see the following table for more information:
| Platform Version | Milestone | Project |
|-----------|------|-----|
| Docker 1.6 | [Docker/1.6](https://github.com/docker/distribution/labels/docker%2F1.6) | [Project](https://github.com/docker/distribution/wiki/docker-1.6-Project-Page) |
| Docker 1.7| [Docker/1.7](https://github.com/docker/distribution/labels/docker%2F1.7) | [Project](https://github.com/docker/distribution/wiki/docker-1.7-Project-Page) |
| Docker 1.8| [Docker/1.8](https://github.com/docker/distribution/labels/docker%2F1.8) | [Project](https://github.com/docker/distribution/wiki/docker-1.8-Project-Page) |
### Package
The distribution project, at its core, is a set of Go packages that make up
distribution components. At this time, most of these packages make up the
registry implementation. The package itself is considered unstable. If you're
using it, please take care to vendor the dependent version. For feature
additions, please see the Registry section. In the future, we may break out a
separate road map for distribution specific features that apply to more than
just the registry.

View File

@ -1,20 +0,0 @@
# The "Distribution" project
## What is this
This is a part of the Docker project, or "primitive" that handles the "distribution" of images.
### Punchline
Pack. Sign. Ship. Store. Deliver. Verify.
### Technical scope
Distribution has tight relations with:
* libtrust, providing cryptographical primitives to handle image signing and verification
* image format, as transferred over the wire
* docker-registry, the server side component that allows storage and retrieval of packed images
* authentication and key management APIs, that are used to verify images and access storage services
* PKI infrastructure
* docker "pull/push client" code gluing all this together - network communication code, tarsum, etc

View File

@ -1,41 +0,0 @@
# Roadmap
## 11/24/2014: alpha
Design and code:
- implements a basic configuration loading mechanism: https://github.com/docker/docker-registry/issues/646
- storage API is frozen, implemented and used: https://github.com/docker/docker-registry/issues/616
- REST API defined and partly implemented: https://github.com/docker/docker-registry/issues/634
- basic logging: https://github.com/docker/docker-registry/issues/635
- auth design is frozen: https://github.com/docker/docker-registry/issues/623
Environment:
- some good practice are in place and documented: https://github.com/docker/docker-registry/issues/657
## 12/22/2014: beta
Design and code:
- feature freeze
- mirroring defined: https://github.com/docker/docker-registry/issues/658
- extension model defined: https://github.com/docker/docker-registry/issues/613
Environment:
- doc-driven approach: https://github.com/docker/docker-registry/issues/627
## 01/12/2015: RC
Design and code:
- third party drivers and extensions
- basic search extension
- third-party layers garbage collection scripts
- healthcheck endpoints: https://github.com/docker/docker-registry/issues/656
- bugnsnag/new-relic support: https://github.com/docker/docker-registry/issues/680
Environment:
- exhaustive test-cases

View File

@ -1,52 +0,0 @@
# DEP #X: Awesome proposal
## Scope
This is related to "Foo" (eg: authentication/storage/extension/...).
## Abstract
This proposal suggests to add support for "bar".
## User stories
"I'm a Hub user, and 'bar' allows me to do baz1"
"I'm a FOSS user running my private registry and 'bar' allows me to do baz2"
"I'm a company running the registry and 'bar' allows me to do baz3"
## Technology pre-requisites
'bar' can be implemented using:
* foobar approach
* barfoo concurrent approach
## Dependencies
Project depends on baz to be completed (eg: docker engine support, or another registry proposal).
## Technical proposal
We are going to do foofoo alongside with some chunks of barbaz.
## Roadmap
* YYYY-MM-DD: proposal submitted
* YYYY-MM-DD: proposal reviewed and updated
* YYYY-MM-DD: implementation started (WIP PR)
* YYYY-MM-DD: implementation complete ready for thorough review
* YYYY-MM-DD: final PR version
* YYYY-MM-DD: implementation merged
## Editors
Editors:
* my Company, or maybe just me
Implementors:
* me and my buddies
* another team working on a different approach