Pre-release workflow
I think this is what we need to do to be able to pre-release branches pre-fixed with /next
This would work from the changeset files alone!
How it works
- if the branch has
next/prefix - If the packages changed in the branch are already in pre-release state
- new pre-releases will be re-released when new changesets are added!
The branch just needs to be prefixed with next/
CC @thomasheyenbrock @dotansimha
(I change the canary scripts slightly here, mostly to clean up, i think everything should still work).
TODO:
- [x] pre-release script and action
- [ ] does git push back to the
next/branch work? - [ ] pre-release comment that gets updated ala canary using pr comment action
- [x] logic that filters out non-prerelease releases! 👀 and prevents forks from publishing from
next/branches
⚠️ No Changeset found
Latest commit: a3e0c689a7a857ebe9705dd1854878ca1f1d37e1
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.
@dotansimha what do you think of this approach? Do you foresee any issues?
labelling do not merge until we are able to test this PR. I guess it should only impact PRs prefixed with next/