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!

[thibaudcolas]

If I’m not mistaken, what’s described here is what’s been done manually as a support task for Django over the years: #11341; #10748; #9906; #9525; #8520; etc

@stsewd is this something you would be prepared to do for other projects as a support task, or should we wait for this to be officially supported?

We’re in the exact same situation as Django for Wagtail. We currently publish versioned docs with tags, and we need to switch to branches so we can update docs of past versions (our Sphinx theme has compatibility issues with the new Read the Docs addons). And likely stop publishing separate docs per patch release. So we’d want stable/5.1.x to be aliased to 5.1.x (or possibly 5.1, TBC).

[stsewd]

@thibaudcolas we will likely first allow users to change the slug or create an alias manually #9684 before adding an automation rule. But these issues are still pending some decisions, you can request changing your version slug by emailing us to support, just note that any existing version with the old slug will 404, and you need to trigger a new build on the branch/tag that was renamed.