rebase ;)

+1. The cleanup seems straightforward and mostly UI related. Love the terminology changes and the formalization of tag as version.

Happy to help test once this is rebased and deemed ready.

Love the terminology changes and the formalization of tag as version

+1 on the image/version terminology. i mostly found repo/tag to be confusing.

I am +1 on image but I am -1 on version because:

1. Versions have strong meaning in the dev/sysadmin world.
2. Docker images are not linear - they are a graph - representing this as a version will cause confusion, for example what happens if you go back up the graph? Does that increment the version or decrement it?
3. If we're not specifying a versioning scheme and we allow arbitrary version strings then we're creating a chaotic and multi-headed hydra of "versions". Everyone will implement different - how do we help people using public images to pick a version if version has potentially a thousand ways to be expressed? Is 1.0 of a image good? Is 20140324a good? Is it production or stable?

Versions have strong meaning in the dev/sysadmin world.

Yes. And tag is already used to convey that meaning in Docker world (irrespective of how we document it, today people use tags as versions).

Docker images are not linear - they are a graph - representing this as a version will cause confusion, for example what happens if you go back up the graph? Does that increment the version or decrement it?

Docker does not care about that. I would argue it's exactly the same as publishing a python package on pypi. What happens if I publish version 2.0 from an earlier git commit than version 1.0 (for example after rebasing, or republishing a new build of 1.0). Answer: nobody cares because it's orthogonal.

If we're not specifying a versioning scheme and we allow arbitrary version strings then we're creating a chaotic and multi-headed hydra of "versions". Everyone will implement different - how do we help people using public images to pick a version if version has potentially a thousand ways to be expressed? Is 1.0 of a image good? Is 20140324a good? Is it production or stable?

Replace the word "version" with "tag" and you are describing exactly today's situation.

We are only talking about making it more obvious how people actually use TAG: as a "chaotic multi-headed hydra" which overall seems to work well enough :)

Yes. And tag is already used to convey that meaning in Docker world (irrespective of how we document it, today people use tags as versions).

Sure but they also use tags as tags. And it doesn't change the fact that version has a strong meaning.

Docker does not care about that. I would argue it's exactly the same as publishing a python package on pypi. What happens if I publish version 2.0 from an earlier git commit than version 1.0 (for example after rebasing, or republishing a new build of 1.0). Answer: nobody cares because it's orthogonal.

Docker may not care about it but users do. Anyone downstream of the example you've just given is going to be annoyed. There's a whole heap of reasons why that's a problematic behavior. Especially that it breaks people's common sense assumptions about versions and progess.

Replace the word "version" with "tag" and you are describing exactly today's situation.

No - it's not. Tags are just tags. Versions have much stronger meaning. People associate value with specific versions - for example the whole "When is Docker 1.0 going to be released?"

We are only talking about making it more obvious how people actually use TAG: as a "chaotic multi-headed hydra" which overall seems to work well enough :)

I am confused - are we deprecating tags or not? Commit says yes - this comment seems to suggest no?

Rebased to keep TAG because arguing over this is really not worth my time right now.

@jamtur01 part of the reason Docker exists is because system packaging tools are stupid about versions and therefore cannot cope with the real meaning people project on "version".

When you say "version has a narrow meaning" you are really saying "... for legacy packaging tools". I argue that this "narrow meaning" you describe is out of touch with the reality of how real people, writing and using real software, reason about versions.

Is "raring" a version of Ubuntu? Is "latest stable" a version of Linux? Is "tonight's nightly build" a version of Docker? Is "bob-test-feature-build42" a version of the web app Bob is working on? According to your "narrow definition" and to legacy packaging tools, the answer is no. But I argue that in these various real life scenarios, the answer is "yes". You can call it a "tag" or a "flavor" if it maps better to your experience with legacy tools. But it doesn't change the reality of how people actually reason about versions - it's messy and ad-hoc, and any packaging tool not equipped to deal with that will fail.

But like I said - I'm not in rush. We can argue over this later :)

I think the major point that is being made about versions is that the only real reason to change from tag to version is if we're going to meaningfully utilize that change. I for one can think of an extremely useful case for changing tags to versions and thats for building package managers ontop of docker (some day). However the only way to do that is to enforce that the content of those versions adhere to a convention where the versions are actually comparable for the use in resolving dependency versions. I'm pretty sure (as in I know for certain) that non-standard version strings in the Python world is a huge pain in the ass for utilizing packages that don't follow the convention.

If we were going to move tags to versions, I think we would be making the same silly mess as PYPI has done in this regard. It would be trivial to implement this enforcement too. But without moving to a meaningful version'ed type of tagging, I just don't see the value in this change.

Another thought is that, our repos can currently support any use-case, whether you want to tag different versions of the same software, or have a repository represent an entire stack of components. We have no way of enforcing the former, so it seems odd to turn the latter into a dirty practice.

That said, I can understand how business pressures force us to think how to fit provenance and so on into all of this.

Also from the maintainer of PYPI,

dstufft | PyPI does require a version to register
dstufft | ldlework: pip since 1.4 excludes things it can't parse by default
dstufft | as in it just assumes that if it can't parse them it must be a pre-prerelease

This has nothing to do with business pressure!!!

If I had to argue this much for every previous iteration of the user experience, Docker would never have launched! Jesus.

(more conversation on IRC around https://botbot.me/freenode/docker-dev/msg/12791832/ )