You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
stsewd
added a commit
to stsewd/readthedocs.org
that referenced
this issue
Sep 24, 2019
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?
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!
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:
1.0
,1.1
, and2.0
versions active in docs. On release of2.0.5
, the2.0
alias will automatically repoint to this new tagversion-3.0
to show up as3.0
automatically.Some rule example psuedo logic are:
2.1
]{match[0]}.{match[1]}
]Work
{major}
,{minor}
,{\1}
(regex grouping), etcThe text was updated successfully, but these errors were encountered: