Buildkit: dockerfile: rename experimental channel

Created on 8 Sep 2020  路  8Comments  路  Source: moby/buildkit

The experimental channel name in docker/dockerfile:experimental is scary to users who think that if they use it their Dockerfile could break in the future. That is not the case; experimental just means that this channel does not use semantic versioning.

We could rename to a less scary name. Old images would still be accessible from current names.

Not sure what the name should be, some options: extended, external, next, plus, x.

aredockerfile

Most helpful comment

"next" LGTM

All 8 comments

"next" LGTM

I need to think a bit more about this. Some quick thoughts/associations that come up when reading the suggested names;

The experimental channel name in docker/dockerfile:experimental is scary to users who think that if they use it their Dockerfile could break in the future

Is there a _guarantee_ that features that are currently in "experimental" graduate? Is there a chance features don't make it? Could there be breaking changes in the syntax between experimental versions before they graduate?

Not sure what the name should be, some options: extended, external, next, plus, x.

Naming is hard on this one; they all have "parts" of their meaning encoded in the name, but

  • "next"

    • 馃憤 Implies it's features that will be coming

    • 馃憥 Implies that all features that are in "next" will be in the next stable (whereas individual features may graduate, and others may not at the same time?); it's also unclear what "next" is (next release of buildkit? docker? ... ?)

  • "extended"

    • 馃憤 Indicates it offers more features than the regular Dockerfile syntax

    • 馃憥 does not capture that this are features that will be added to the regular Dockerfile syntax at some point. It feels more "permanent"; _"these are features that will always only be available in the extended ("advanced") syntax"_

    • As a user (because of the above?) I'd be wondering: why do I have to use a special syntax to use these features; they're not in the way of "non-advanced" / "non-extended" use of the Dockerfile?

So, I guess it depends a bit on how we want to actually add, and graduate features:

  • Would we be comfortable with always graduating all features in "experimental" to "stable"?
  • Would we be comfortable with adding features to "experimental" _only_ if we're sure they will make it into the next "stable"?
  • What will be the release-cadence for the stable syntax; will it (continue to) have its own release cycle and versioning, will it coincide with docker releases?

Based on the above, "next" could work. Possible alternatives could be "early-access"

i like next

Is there a guarantee that features that are currently in "experimental" graduate? Is there a chance features don't make it? Could there be breaking changes in the syntax between experimental versions before they graduate?

No. The features may not graduate and may be removed. The guarantee is that the existing image will continue to work even if you update buildkit/docker. The future versions of the image may not be compatible with the older version.

Even if scary, I think the name experimental describes very well the status of that tag.

The community will find experiments that will may or may not become part of the official codebase. There is something else we can do to make them next scared? Like writing a notice log when buildkit starts that says: experimental won't break your images by purpose. We are nice people, not troublemakers.

Discussing;

  • Irregardless of naming, we should better document what promises/expectations users can have
  • Using :experimental without version is similar to :latest, so yes, that can be risky. Experimental _does_ allow removing features, or changing their behaviour. _However_ if you "pin" to a specific version of experimental, users can continue using.
  • That said; so far, we haven't removed a feature, but if we would at some point, we can provide a clear error that instructs them to "use version-older-version to remain using "<insert removed feature>"
  • Could also print message if experimental feature that is used has graduated to stable (you can now use docker/dockerfile:1.x)
  • (we should promote more to specify syntax, even if it's the default / "stable" see https://github.com/moby/moby/issues/4907)

Related to the docs: https://github.com/moby/buildkit/issues/756 (add a readme to docker hub)

"fast channel"? "insider" ?

How about labs ? It's like experimental but not experimental (cannot be confused with other experimental stuff in docker).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

thaJeztah picture thaJeztah  路  5Comments

skaegi picture skaegi  路  3Comments

daveisfera picture daveisfera  路  3Comments

tonistiigi picture tonistiigi  路  4Comments

kenotsolutions picture kenotsolutions  路  4Comments