Revise release process following discussion with @edsilv. #1252
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes a few adjustments to the release process, following a discussion with @edsilv:
1.) It notes that we are inspired by Gitflow, rather than saying that we exactly follow it; our process is very similar but has some minor variations. We can certainly discuss whether we want to switch to a more "pure" Gitflow workflow, but for now I want to accurately reflect what we've already agreed upon.
2.) It makes sense to publish our release candidates on NPM, so the workflow has been adjusted to ensure that that happens. (This is something that @edsilv, and likely others, will need in order to test RCs effectively).
3.) The main area in which our workflow differs from Gitflow is in how release branches are handled. Gitflow uses short-lived release branches that only exist while the release is being actively worked on. We use long-lived release branches for the purpose of backporting bug fixes. I have revised the branching here so that we actually use BOTH -- we create a short-lived
release-X.Y.Zbranch during the release process to follow Gitflow, and then we retain/maintain a long-livedrelease-X.Ybranch after the release to support backporting of fixes. This feels like a "best of both worlds" solution, and it also makes the actual release process significantly easier to explain, because there are no longer so many edges and special cases. The only potentially confusing part is having branches namedrelease-X.Yandrelease-X.Y.Z, with the significant difference being only the number of digits in the branch name. We can refine our naming conventions if we need to!