Closed eloquence closed 4 years ago
One alternative that we discussed briefly was to maintain a stable
tag. The process for pushing docs applicable to the latest release could be:
develop
as usualstable
tag.The current release branch would then always have two tags:
stable
build of the docs.Advantages of this approach:
Disadvantages as I understand them:
develop
by accident, pulling in lots of commits that aren't applicable to the current release versionstable
branch behavior, but not the tag behavior yet)Ultimately I don't personally have a strong preference here, either approach seems much more manageable than manual merges or rebases.
This was completed via #5441.
For the last two releases, we've experimented with using our historical
master
branch to build the docs, motivated by avoiding links to outdated docs (#5081) and the fact that we have to merge docs changes after the release tag is signed.This has been a mixed success. We have resolved #5081, but the branch merge tends to require significant manual conflict resolution, and the git log on
master
is no longer an accurate reflection of the commit history.We've agreed to build the branch from a new name (#5321) that is more descriptive. As part of that change, we should also finalize the procedure for updating the branch after each release.
During standup on 6/18, there was broad support for a strategy based on force pushing the branch into the state of the release branch, as part of the release cycle. The exact steps will need to be clearly documented to minimize room for error.