feature: mutate existing GitHub releases

[MattSturgeon]

This may well be out of scope for this project; I won't be offended if this is marked as "WONTFIX".

The GitHub API has decent support for updating existing releases.

Use case

Many Minecraft mods target multiple Minecraft versions using backport (or forward-ported) branches. While some have different project versions per branch, others share a single project version across all targeted Minecraft versions.

For example Freecam released version 1.2.3 targeting 1.17, 1.18, 1.19, and 1.20. There was one "canonical" tag (v1.2.3), which has an associated GitHub Release. While the various "backports" have tags (e.g. v1.2.3+mc1.20.4), they don't have their own GitHub Release so the build artifacts are instead uploaded to the main v1.2.3 release.

Suggestions

Options focused around what the publishGitHub task should do when the target release does/does not already exist.

Bear in mind, I'm throwing ideas at the wall here to see what sticks...

• [ ] Verify Tags: fail if the tag does not already exist
• [ ] Update only: fail if the release does not already exist
• [ ] Create only: fail if the release already exists
• [ ] Lenient: log info whether the release already existed; continue regardless
• [ ] Upload strategy:
  • [ ] Append: add new artifacts alongside existing ones
  • [ ] Replace: remove existing artifacts before uploading
• [ ] Release notes/changelog strategy:
  • [ ] Fail if different
  • [ ] Warn if different
  • [ ] Replace if different
  • [ ] Append if missing
  • [ ] Append always
• [ ] Name/title strategy:
  • [ ] Fail if different l
  • [ ] Warn if different
  • [ ] Replace if different
• [ ] Tag options
  • While you must reference a release using it's current tag, you can specify a new tag to associate the release with.
  • To support this you would need a way to specify the existing release tag to update separately from the "version" being published.
  • IDK if there is a use-case for migrating a release from an old tag to the new "version" tag...

Failure could mean "do nothing", "warn and cancel", or "throw and panic" depending on user config...

[hypherionmc]

I'll take an in-depth look at this and see what is missing from our current implementation.

Currently, we do have support for adding files to an existing tag. Since the plugin is designed with multiple modloaders in mind, we first check if a tag exists (matching the version), and if it does, we add the files to it. If it doesn't, it's created and the files are uploaded

[MattSturgeon]

Currently, we do have support for adding files to an existing tag. Since the plugin is designed with multiple modloaders in mind, we first check if a tag exists (matching the version), and if it does, we add the files to it.

That's good to know. Sounds like you're already pretty much there for most simple scenarios! 🎉

I guess this issue just covers having a bit more control where you think it's worth the complexity & maintenance burden.

IDK if there is a use-case for migrating a release from an old tag to the new "version" tag...

This may actually be really useful for Freecam, specifically, if it were able to "glob" for a release based on tag and also update the release's tag.

Alternatively, matching on release name/title may also work (and may be simpler). But both require iterating through "list releases", since you can only "get" a specific release if you know the exact tag or id.

This would enable bootstrapping & reducing a release. By creating a release using the first tag pushed (e.g. v1.2.3+mc1.17), then migrating the release as each new tags get pushed, until eventually it ends up migrated to the "canonical" tag (v1.2.3), at which point any tags pushed wouldn't modify the release's tag.

This may well be totally out of scope for modpublisher, unless maybe some kinda provider/filter/whatever functional APIs could be exposed 🤔

I'm totally happy writing custom buildSrc code to cover niche usage that doesn't fit within this plugin. If we go down that route I'll probably end up opening more specific issues/PRs if there's any API level stuff that'd help.