From 07250457df03396ea61dbf3782b5f8cf1094e7e0 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Wed, 3 Aug 2016 17:17:54 +0200 Subject: [PATCH] Remove Dockerfile syntax from frozen features As discussed on the maintainers mailinglist, and during a maintainers review session; We've recently made changes to the Dockerfile syntax (e.g., `HEALTHCHECK`, `SHELL`), so mentioning the Dockerfile syntax as a frozen feature is no longer accurate. Removing it from frozen features does NOT automatically state an intent to make big changes to the syntax; making changes to the syntax are important decisions and should never be taken lightly. This change is just to indicate that we can *accept* changes if they are meaningful, and we're confident they can be made. Signed-off-by: Sebastiaan van Stijn --- ROADMAP.md | 23 +---------------------- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 514fdb7423..dc6b133787 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -93,28 +93,7 @@ to another node in the cluster. This will be introduced in a backward compatible We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a *debugging* feature, as well as being strongly dependent on the Runtime ingredient effort. -## 2.2 Dockerfile syntax - -The Dockerfile syntax as we know it is simple, and has proven successful in supporting all our -[official images](https://github.com/docker-library/official-images). Although this is *not* a -definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several -reasons: - - - Long term impact of syntax changes is a sensitive matter that require an amount of attention the - volume of Engine codebase and activity today doesn't allow us to provide. - - Allowing the Builder to be implemented as a separate utility consuming the Engine's API will - open the door for many possibilities, such as offering alternate syntaxes or DSL for existing - languages without cluttering the Engine's codebase. - - A standalone Builder will also offer the opportunity for a better dedicated group of maintainers - to own the Dockerfile syntax and decide collectively on the direction to give it. - - Our experience with official images tend to show that no new instruction or syntax expansion is - *strictly* necessary for the majority of use cases, and although we are aware many things are - still lacking for many, we cannot make it a priority yet for the above reasons. - -Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about -what we want to do first! - -## 2.3 Remote Registry Operations +## 2.2 Remote Registry Operations A large amount of work is ongoing in the area of image distribution and provenance. This includes moving to the V2 Registry API and heavily refactoring the code that powers these features. The