Open KyleAMathews opened 3 years ago
Hi! Thanks for looking into Changesets. I remember talking with @wardpeet about this stuff but I don't recall the exact problem and unfortunately, our chat history is not accessible as we've been talking in a free (or smth) Slack workspace.
Could you describe your workflow in more detail so I could give you proper advice on that one? Especially details around what is automated.
Hey @Andarist,
I was trying to find it too. Our workflow looks like the following:
Every PR gets merged into master. We publish pre-patches with preid next (3.3.0-next.0
).
We create a release branch from master (release/3.3) it will remain there for about 4 weeks. We cherry-pick commits/PRs if we need to backport fixes. Than we do a patch publish.
Currently we use lerna to publish our packages to keep transitive versions in sync.
I’m still unsure if I understand your complete workflow but I think that little to no changes would have to be done in Changesets so you could use them.
1.2.0-dev20210405
(the exact format might be slightly different as I’m writing that from memory)Does this sound good? Or is some requirement missing here?
Hopefully, after our private chat it became a little bit more clear. Something that's missing from the above comment is that I'm not sure how we would patch a previous release.
This is roughly how we do it now, in a sketch. We don't have to keep this structure as long as the behaviour stays the same :)
Our model is pretty much the same as described here: https://trunkbaseddevelopment.com/branch-for-release/
So we never publish stable releases from trunk. And also the same change may end up in multiple releases - next minor and backported to the previous minor (and sometimes previous major) as a patch.
The important thing to realize about changesets is that "release intents" (changesets) are kept on disk/in git. This has some implications on the workflow you are using - it's not that it's not possible to support it but it would be the easiest to change it a little bit to what we need here. If the proposed approach won't work for you for some reason - then we can discuss this further, I'm also open to setting up a call to figure out a suitable workflow for you.
rc-channel
each 2 week
rc-channel
, when anything new lands there a versioning PR will get open against the rc-channel
rc-channel
all scheduled to release packages will be released under rc
tagstable-channel
somehow, but I'm not sure yet how exactly to accommodate that using GitHub UI alone. Worst case scenario this could be scripted from the rc-channel
so the exiting PR would not be active throughout the whole stabilization period but rather just when you decide to manually~ invoke the script to create itThis doesn't seem to be overly complicated to me and would utilize the Changesets in a pretty straightforward way.
Fixing PRs are somewhat problematic - if merge/cherry-pick/whatever a fixing PR with a changeset to either rc-channel
or stable-channel
branches then Changesets will create versioning PRs for them and you will be able to merge them (this allows you to batch multiple fixes in a single release per channel). So far so good. The problematic part is that in the current workflow you merge fixing PRs to master and cherry-pick that to other branches - but we'd like to remove the changeset itself from the master as otherwise it would become a part of the future RC release and that's not what you want to achieve. So my proposal would be to actually prepare those fixing PRs against other channels and cherry-pick to master which would allow you to drop the changeset file in the process.
An alternative solution for that would be to somehow mark the changeset as belonging to a different release which would allow us to ignore it (and remove it) when force pushing to the rc-channel
. This would result in the extra commit on master as we'd have to alter git content to remove those changesets. This one would require a minor feature to be added to Changesets.
Please tell me how does it feel, what do you think about the proposed workflow and the workflow related to fixing PRs. Are there any particular things that you don't like about it? Is everything clear? Or should I explain some part of this in more detail?
We're looking into using changesets for Gatsby to generate better Changelogs. We use a release branch workflow where every two weeks, we create a new branch of master e.g.
releases/3.2.0
and then publishlatest
from there.@wardpeet said he'd talked to one of you and that changesets would need some changes to support this flow? If we can help out, let us know!