Add alias support to version automation

[agjohnson]

In #4001 we started by adding version automation rules to enable new versions.

In this next phase, we will address the use case of automation of version aliases. Prior to this, we might need to refactor how we are managing version alias, and potentially more widely support alias management in our UI.

Example use cases here are:

• User want to set up aliases for minor versions that point to bugfix releases. For instance, a project has 1.0, 1.1, and 2.0 versions active in docs. On release of 2.0.5, the 2.0 alias will automatically repoint to this new tag
• User has an odd branch naming convention, wants to automate adding versions derived from these branch names. For instance, project repository uses major version branches for backporting use and wants version-3.0 to show up as 3.0 automatically.

Some rule example psuedo logic are:

• On [Regex match /2.1.[\d+]/], [Set alias 2.1]
• On [Regex match /([\d+]).([\d+]).[\d+]/], [Set alias {match[0]}.{match[1]}]

Work

• Add an action "Set alias". This action supports some templating, such as the docker hub version automation -- {major}, {minor}, {\1} (regex grouping), etc
• Add UI pieces for rules, if anything new is required in our UI

[stsewd]

Another use case is for users that have versions not compatible with pep 440, instead of renaming all of their versions, they can just rename the slug on rtd and automate this with automation rules. We want to allow users to edit the version slug first.

[helderco]

This seems like the right fix for my use case, let me know if this is true.

I have a python library in a monorepo with components in other languages. For this library, new versions are released by pushing a new sdk/python/v<semver> tag.

Would this feature allow extracting the semver from the tag and use that? Would it also work to set stable?

[stsewd]

This seems like the right fix for my dagger/dagger#3767, let me know if this is true.
Would this feature allow extracting the semver from the tag and use that?

Yes, if implemented, this would solve your problem. Thanks for commenting your use case!