Consider merging .NET Framework Runtime and Builder Docker repos about dotnet-framework-docker

[SteveDesmond-ca]

Docker tags are similar to SVN tags in that there are conventions around how they should be used, but no hard rules -- a tag can be something completely arbitrary and not related to the project at all. Contrast this with git tags, which have a very specific purpose: naming a point in history of a repo. I like to think of Docker tags more like git tags, naming a point in history of a project (in this case, a release).

I've definitely seen both suggestions in the wild, for both having different tags/repos for builds with different base OS images, and having different tags/repos for different feature subsets / configurations (like we're talking about here).

My opinion as a more experienced Docker user is, if the builder and runtime images are intended for fundamentally different purposes (and I believe they are), they should live in different repos.

[richlander]

Here's another good example: https://hub.docker.com/_/openjdk/. It uses the same model as the .NET Core repo.

My opinion as a more experienced Docker user is, if the builder and runtime images are intended for fundamentally different purposes (and I believe they are), they should live in different repos.

This is part of the rub. In the cases of both .NET Framework and .NET Core, the SDK/builder image contains the runtime, too, so it offers a superset of scenarios, not a disjoint set. I assume that this is the same with Java as well.

[richlander]

I have been thinking more about this. If we do this, the naive approach would be to add a new build tag as a direct translation of the microsoft/dotnet-framework-builder repo. The build tag would behave much like the sdk tag we use in the microsoft/dotnet repo. But then, why wouldn't we re-use the sdk tag instead? That seems accurate and would make it easier to talk about .NET Framework and .NET Core repos.

The only downside is that the current microsoft/dotnet-framework-builder images don't contain the .NET Framework SDK (certainly not in its entirety). I'd say that any .NET Framework SDK tool that is relevant for use in Docker is fair game for being pulled in.

[SteveDesmond-ca]

I like what PHP has done around your last point, by providing a Docker-specific way to consistently and easily install extensions -- check out the docker-php-ext-installsection here -- this keeps the base image smaller and (a benefit in my opinion) leads to explicitly stating those types of dependencies.

[richlander]

That makes sense. For our platform, we don't have the extensions in a package manager, like NuGet. So, I don't see a good path forward to enable the proposal.

[MichaelSimons]

The repos were merge with #123.