Proposals: Pick requests -> Pick PRs and creating 0.xx-unstable and 0.xx-stable release branches

[lunaleaps]

Problem 1:

• Pick requests have historically been placed on the onus of the release POC to pick and release a patch
• Pick requesters are blocked until their pick gets selected etc.

Proposal 1:

• Let's move pick requests to be pick PRs
• Release POCs can decide whether to merge, and we get CircleCI signal
• Build artifacts per PR will be available so requestors can also use those to unblock themselves or test

Problem 2:

• Work on "automated release pushes" (where we basically run bump-oss... script on CircleCI) will then release a new patch release every time a pick PR is merged.
• Not 100% sure this is a problem but if we did want to be more in-control of our patch numbers, then...

Proposal 2:

• Let's create 2 branches for each minor release, -unstable and -stable. The idea being that pick PRs are made to -unstable and when ready for a full "formal" release, we merge un-stable into stable.
• This also gives us flexibility to get a build artifact off a stable/pre-release, but potentially revert on -unstable if we don't want it in the actual release

Thoughts?

[NickGerleman]

Proposal 1 makes sense to me.

Is the goal for proposal 2 to allow greater flexibility in how we aggregate changes into a release? Having multiple branches per version seems like it might add a bit of overhead, so I am wondering how the solution compares to alternatives which only use the one branch.

[lunaleaps]

Yea, I think proposal 2 is a response to the fact that if we request picks to be done as PR then as they are merged into 0.xx-stable, a new release patch will occur. So we won't be able to bundle picks together anymore -- at least the way its currently configured.

If that is a problem, and we don't want to do a 2 branch approach, then maybe we need to change the way we trigger a release. Right now this happens on a push but maybe it should be POST or by pushing a certain git tag on the commit etc.

[NickGerleman]

GitHub Actions and Azure Pipelines both have UI to allow manually starting a workflow/job. It seems like a good fit for this kind of problem, but I'm not sure if it translates to CircleCI.

In RNW we just schedule the scripts to run once a week, and don't do any other manual work for patch releases. But we also have the scripts create the release notes on Github, etc. It's had pros and cons, but I overall think the time savings have been worth it.

[kelset]

Proposal 1 is ok but I fear it might push away some folks who might want to report a problem, but don't feel able to do a PR against react-native. For context, in my experience the complexity of RN OSS repo has been a long time problem pushing away potential contributors.
The other concern/question I have about this is that historically the CI on stable branches tends to get red very very quickly. Even in the 0.66 branch many CI jobs  are ❌ currently. So I think that we should "gate" this proposal behind the requirement of having CI ✅ on stable branches too.

Proposal 2: I think there's something interesting to explore with the idea of multiple branches to solve those problems, but I'm not a fan of having to maintain multiple branches in sync. Nor I think that in general RN should have some automated process for releases, there should always be a manual step of someone pressing a button to trigger a release.

[tido64]

For proposal 1, I liked Nick's idea of making it super-easy for folks to request a pick. For instance, requesters can leave a comment with a command + reason, e.g. /cherry-pick 0.64-stable This is a regression , on the PR that a bot will pick up and create a PR against the stable branch. We can then discuss on the PR itself whether it makes sense to merge it, or maybe the bot will leave a comment in the appropriate release discussion. Extra bonus if the bot can tell the requester that it cannot pick unmerged PRs.

For proposal 2, I don't like the idea of multiple branches. It's easy to lose sight of what's been merge and what hasn't. We already have that problem today with just -stable branches.

[cortinico]

I second the general consensus here. 1 sounds like a good addition to me, but I would not make it a hard requirement. It should still be possible to request for a pick of a commit against the release branch (that can be automated with the command suggested by @tido64).

As for point 2, I believe it will be harder to keep the two branch in sync + naming a branch as -unstable will entice people away from testing it. I'd be for keeping just the -stable branch as it is and push on it any pick that is requested.

[lunaleaps]

Cool, I think I'll go with this approach then:

• Continue cherry-picks by release POC
• Tweak release automation to require tagging a commit like release and pushing to a release branch 0.xx-stable. Only then will a release be triggered on CircleCI
  • I don't know how to make a generic "button" so I think this is the lowest effort way without having someone remember a curl req. etc.
• Work on some action/bot that will create PRs for picks in the meantime

[kelset]

could you clarify why you need to run all these tags? Is the overall idea for the method you explained in the first comment here to take over the bump-oss-version from now on? I just want to make sure I'm following, I'm feeling a bit lost.

[lunaleaps]

Yea the original motivation of this work is that bump-oss-version requires some local configuration (like a certain version of ruby and cocoapods) which is a pain for a releaser because depending on what release you're working on, the versions could be different.

I've moved this work to CircleCI which runs the script prepare-package-for-release.js: https://github.com/facebook/react-native/blob/583471bc48ac45e09f6fb16bdb6fe7b1f588e996/scripts/prepare-package-for-release.js

In my v1 approach, I had it so whenever a releaser pushes the release branch to the remote repo, that would trigger CircleCI to publish a new release.

There were a couple of problems with this approach:

1. In having this discussion, and the idea of pick requests coming as pull requests, in this world whenever we merge a pick PR, it would trigger the CircleCI to publish a new release -- not good.
2. You had mentioned that you want the releaser to have manual control of releases which this v1 approach kind of obfuscates.
3. I realized that I didn't account for how to signal when you want to promote something to stable (whoops)

So in my v2 approach, we are still leveraging CircleCI but instead of using remote pushes as a trigger, we use tagging.
Since we no longer need bump-oss-version.js (because the logic has moved to prepare-package-for-release), I have re-written this script to be a CLI to appropriately tag the release to tell CircleCI what to do.

Sorry here is all the code: facebook/react-native#32769

[lunaleaps]

I will be updating the docs and everything once I've smoothed out to make sure things are working as expected (I'm doing some testing on branch 999.0-stable)

[tido64]

Just to make sure I understand your proposal correctly: Are you saying that we should tag the appropriate commit locally, push it to remote, then a CI job will pick it up? What happens to all the "fake" tags? Does the CI validate that we're on right branch, and are using the correct version/format for the tag? What happens if the script fails midway and we get into a weird state with fake tags all over the place?

In general, I'd avoid having temporary state that we have to clean up later. I don't know if CircleCI supports it, but with GitHub Actions, we can trigger a CI job from the command line (or directly in the browser) using workflow_dispatch. My suggestion is that we move as much as possible to the CI. For instance, the releaser invokes something like yarn publish 0.67-stable, which invokes a CI job. The CI's job is to

1. Make sure we are on a -stable branch
   a. If the branch doesn't exist, it creates it and assume we want rc.0 (?)
   b. If the branch exists, figure out what the latest published version is, and bump the version number appropriately for this release
2. Publish the package to npm
3. If the package was successfully published, tag the commit and push back to main

If something fails between 1-3, nothing has changed and we can retry later. This also reduces the human element to just specifying the correct branch at the command line.

Likewise, if we want to promote the build, we should be able to do yarn publish 0.67-stable --promote-to-stable, and let the CI figure out the details.

[lunaleaps]

I think prepare-package-for-release and publish-npm does a lot of what you mention already. I want the releaser to be able to be explicit about the version vs. inferred via the existing published versions.

I think your point about not using intermediate tags makes sense. I think that'd be a question of triggering CircleCI workflows with some data. Currently, these tags are deleted in prepare-package-for-release. Please feel free to comment on the PR