I have started to enable "immutable releases" in my GitHub projects. For my personal projects, I have to enable them per-project. For an organization like clj-commons, we could enable them for all repositories. I have enabled them for durable-queue and slingshot for now.
Does anyone know of any reasons why we would not want "immutable releases" for all clj-commons projects?
Background: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases
I finally got around to setting releases to be immutable for all clj-commons repos (a month after I brought this issue up). Once you make a release, it can no longer be changed. If you need to add files to a release, you need to create the release as a draft first, then add the files, then release it. If this causes a problem for the workflow of your clj-commons project(s), bring it up in the #clj-commons channel and we can discuss what best to do.
does this mean that a released tag can be overridden? if so, then that is the policy i set in place at my company for npm, maven, php and other package types for releases for the last 6 years. Occassionally, someone makes a release by mistake and wants to undo that, but with immutable releases you just roll forward, just like git SHAs are immutable, mostly
Thanks for doing this @seancorfield. > If you need to add files to a release, you need to create the release as a draft first, then add the files, then release it. Are you describing a special-case scenario here? Or do we always need to create a draft release first now?
No, only if the workflow for a project was to create a release and then add files to it (for downloads). That workflow requires a draft first, then add files, then promote to a full release. For most Clojure projects, you just make a regular release, as you did before. You just can't change the tag or add files to a release now.
Cool, thanks!
Sounds fine to me, Sean!
Cljdoc supports a cljdoc-<version> tag, which folks might move, but that has nothing to do with the release tags you are talking about.
I'll wait for a bit more feedback before making any changes (although we can easily undo this later, if we find the workflow problematic)...