Problem
ImageBuilder and its associated templates flow immediately downstream to consuming repos after they are updated. This means that all changes to ImageBuilder must be 100% complete and verified working before they can be safely merged. This does not lend itself well to working incrementally.
For example, some larger changes, like #2166, should be split into multiple commits/PRs - one for creating new artifacts, one for consuming the new artifacts, etc.
Proposal
Adopt a real versioning system for ImageBuilder.
Personally, I like minver. It works by using git tags for versioning information:
- If the current commit has a version tag, use that for the version.
- If the current commit doesn't have a tag, walk backwards to find the most recent tagged commit, bump the version, and add a pre-release suffix + build number.
To create a new (stable versioned) release, you would just create a new git tag and then build.
I'm not sure how this would interact with arcade. You can compute the version outside of MSBuild completely (ourselves, or using minver-cli, a dotnet global tool) and pass it to Arcade/msbuild. Computing outside of arcade also allows us to more easily tag images with a version.
Testing preview changes
https://github.com/dotnet/docker-tools and https://github.com/dotnet/dotnet-docker/tree/nightly should use preview versions, whereas all other repos/branches should use stable versions.
Problem
ImageBuilder and its associated templates flow immediately downstream to consuming repos after they are updated. This means that all changes to ImageBuilder must be 100% complete and verified working before they can be safely merged. This does not lend itself well to working incrementally.
For example, some larger changes, like #2166, should be split into multiple commits/PRs - one for creating new artifacts, one for consuming the new artifacts, etc.
Proposal
Adopt a real versioning system for ImageBuilder.
Personally, I like minver. It works by using git tags for versioning information:
To create a new (stable versioned) release, you would just create a new git tag and then build.
I'm not sure how this would interact with arcade. You can compute the version outside of MSBuild completely (ourselves, or using minver-cli, a dotnet global tool) and pass it to Arcade/msbuild. Computing outside of arcade also allows us to more easily tag images with a version.
Testing preview changes
https://github.com/dotnet/docker-tools and https://github.com/dotnet/dotnet-docker/tree/nightly should use preview versions, whereas all other repos/branches should use stable versions.