Merge pull request #270 from stevvooe/roadmap

Add ROADMAP.md to the project and cleanup existing items

README.md

@@ -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
 ------------
 

ROADMAP.md

@@ -0,0 +1,91 @@
+# Roadmap
+
+The Distribution Project consists of several components, some of which are still being defined. This document defines the high-level goals of the project, identifies the current components, and defines the release-relationship to the Docker Platform.
+
+* [Distribution Goals](#distribution-goals)
+* [Distribution Components](#distribution-components)
+* [Project Planning](#project-planning): release-relationship to the Docker Platform.
+
+## Distribution 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
+
+## Distribution Components
+
+Components of the Distribution Project are managed via github [milestones](https://github.com/docker/distribution/milestones). Upcoming
+features and bugfixes for a component will be added to the relevant milestone. If a feature or
+bugfix is not part of a milestone, it is currently unscheduled for
+implementation. 
+
+* [Registry](#registry)
+* [Distribution Package](#distribution-package)
+
+***
+
+### Registry
+
+Registry 2.0 is the first release of the next-generation registry. This is primarily
+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.
+
+#### Registry 2.0
+
+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))
+
+#### 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)
+
+#### Registry 2.2
+
+TBD
+
+***
+
+### Distribution Package 
+
+At its core, the Distribution Project 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 Roadmap for distribution-specific features that apply to more than
+just the registry.
+
+***
+
+### Project Planning
+
+Distribution Components map to Docker Platform Releases via the use of labels. Project Pages are used to define the set of features that are included in each Docker Platform Release.
+
+| Platform Version | Label | Planning |
+|-----------|------|-----|
+| Docker 1.6 |  [Docker/1.6](https://github.com/docker/distribution/labels/docker%2F1.6) | [Project Page](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 Page](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 Page](https://github.com/docker/distribution/wiki/docker-1.8-Project-Page) |
+

open-design/MANIFESTO.md

@@ -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

open-design/ROADMAP.md

@@ -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

open-design/specs/TEMPLATE.md

@@ -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