prevent overwriting existing versions on dockerhub

[C-nit]

I had to make the experience that an image build where we had based from (tagged) 0.19.1 started to fail later, because the image on dockerhub with that tag changed.

I haven't checked whether you have now already checks in place, but in case not, I would like to encourage you to never "move" tags of versions, with "latest" being the exception.

[wholtz]

Hi @C-nit . Thank you for you interest in micromamba.

I'd suggest you use sha image digests in your Dockerfile FROM line instead of tags. This is generally considered a best practice and is recommended in our documentation.

The change you are requesting would require a significant change in our development model. Currently we allow updates to the main branch of this repo independent of the micromamba executable release schedule. The requested change would require only releasing changes to the image when a new version of the micromamba executable is released. I'm open to moving to such a development model in the future, but it might be awhile until I get around to implementing the required changes.

[maresb]

@C-nit, while not cryptographically guaranteed to be immutable like SHA digests, we expect the Git-based Docker tags should in theory never change.

[wholtz]

Now that micromamba has reached v1.0, I will be aiming to only commit changes to the image build process when new major or minor versions of the micromamba program are released. This change was implemented for the v1.3.0 release of micromamba, where I reworked the build to support alpine linux. The changes for alpine and the addition of an alpine-based image were merged along with the bump to v1.3.0 of micromamba.

However, I want to be clear that this project will continue to use 'rolling tags' so that we can incorporate upstream security fixes from the base images we build on top of. If you want to ensure that you will always get the exact same image, you should use SHA digests or one of our tags containing "git".

[maresb]

@wholtz, how will the release workflow work now? Will we wait for the next micromamba release before merging non-critical PRs into main? Should we remove https://github.com/mamba-org/micromamba-docker/blob/6aa1f7c707562edb9f8dc9005d12cf6a39e8f0b4/.github/workflows/push_latest.yml#L5-L7 so that merging doesn't automatically trigger a rebuild?

[wholtz]

Changes that can still use the old workflow:

• bumping versions of existing base images
• removing a base image that is no longer supported
• documentation enhancements
• testing changes
• security updates

For everything else, we now have a dev branch, which is protected. New work should start as new branches off dev and then generate PRs to merge into dev. When a new micromamba version comes out, I'll run update.sh to bump the version numbers on dev and then merge dev into main.

While documentation enhancements can go through the old workflow, documentation for new features should be committed to dev along with the code for the feature.

As always, let me know if you have feedback @maresb.

I'll work on getting this info into the Development section of the README.md.