|
@@ -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
|
|
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.
|
|
*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
|
|
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
|
|
moving to the V2 Registry API and heavily refactoring the code that powers these features. The
|
Tibor Vass