Open humitos opened 1 year ago
The procedure is more or less the following:
v1.0
, v1.1
, etcv1
and v1.1
points to exactly the same commit hashv1.2
, we will need to re-tag v1
to point to that new commit hashgit push --delete origin v1
) and re-tagging it (git tag v1 <new hash>
)v2
and v2.0
release/v<major>
branch has to be rebased with the changes from origin/main
* this is done by deleting the old git tag (`git push --delete origin v1`) and re-tagging it (`git tag v1 <new hash>`)
This should be handled by GH workflow, seems rather straightforward to implement with appropriate regex to avoid recursive calls. How about latest
tag as well?
Merging #16 will make us to do a release of the
v1
again. We want to follow what we talked at https://github.com/readthedocs/actions/issues/5#issuecomment-1197688541This basically means re-tagging
v1
to point to the latest commit that includes thesingle-version
option.Since this release process is no the common for other repositories, we need to document it in a clear way, so it's easy to follow.