Summary:
A small backport to main of a local fix done in 0.71 to account for the logic for releases 0.Y.1,2,3-prerelease (meaning, not just strictly 0).
I could have done like the other logics and just remove the check for patch, but decided to at least make sure it's a digit 😅
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - handle patch versions after the .0 for set version
Pull Request resolved: https://github.com/facebook/react-native/pull/36020
Test Plan: Tested in 0.71-stable, without it we can't test RNTestProject.
Reviewed By: jacdebug, cortinico
Differential Revision: D42924375
Pulled By: cipolleschi
fbshipit-source-id: b003d884cc45a2602adbc14fa8b66d3f1e0c94a6
Summary:
The nightly version is bumped after the check is performed, therefore it fails.
With this diff, we become slightly more accepting with nightlies, allowing both `0.0.0` and `0.0.0-xxxx` as valid version for nightlies.
## Changelog
[JS][Fixed] - Accept 0.0.0 with and without prelrelease for nightlies' versions
Reviewed By: cortinico
Differential Revision: D41534995
fbshipit-source-id: 2d0417441ca7d3d3f7660c9317133ac3c6de2eb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35296
This change adds some version checks and enforces that every version matches some specific format based on the build type we are trying to run.
## Changelog
[General][Changed] - Improve version checks
Reviewed By: cortinico
Differential Revision: D41161756
fbshipit-source-id: 4172195c5e031c1eaf7b33bb74f381c04e9adaf5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34694
TL;DR Relax the assumption of having git to build the RN NPM package.
We do have two CI Systems: CircleCI for OpenSource and Sandcastle for Internal. It's crucial that the two CIs are aligned.
We currently don't have a way to test the new app template on Sandcastle for Android & iOS.
This results in scenarios where internal Diffs gets landed and break the public CI externally.
This is preparation work to then be able to build the RN NPM package in Sandcastle (which will be done in a follow-up diff).
With this we also introduce the restoring of all the changed files after the publishing script is done.
## Changelog
[Internal] [Added] - Made it possible to create publishing NPM packages in Sandcastle.
Reviewed By: cortinico, cipolleschi
Differential Revision: D39467471
fbshipit-source-id: b0de88a768b8a2fb798dd684fa8f97f4d0acb751
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32757
Changelog: [Internal] - Update release automation to still be manually triggered as from discussion: https://github.com/reactwg/react-native-releases/discussions/7
A releaser needs to do the following on a release branch like `0.99-stable`:
* For an initial release branch cut:
* Tag the head of the branch `git tag publish-v0.99.0-rc.0`
* `git push origin 0.99-stable --follow-tags`
* For cherry-picks on the pre-release:
* Make the picks on `0.99-stable`
* Tag the head of the branch `git tag publish-v0.99.0-rc.1`
* `git push origin 0.99-stable --follow-tags`
* For promoting pre-release to stable with intention of making this the `latest` npm version:
* Tag the head of the branch `git tag publish-v0.99.0`
* Tag the head of the branch `git tag latest`
* `git push origin 0.99-stable --follow-tags`
Follow-up diff to make this codified via a script
Reviewed By: sota000
Differential Revision: D33101594
fbshipit-source-id: 74b065229a3705fccbe1a25ed7ece4a28d9aa76d
Summary: Changelog: [Internal] Add a `isTaggedVersion` function to filter out commits from release automation.
Reviewed By: sota000
Differential Revision: D32842035
fbshipit-source-id: 14bb262a1d2a96ffda87c759a3202c4f9a356141
Summary:
Changelog: [Internal] - Extract logic from bump-oss-version specific to prod releases
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `prepare-package-for-release` script referenced by extracting it out of `bump-oss-version` and leveraging `set-rn-version`. It adds some helper functions to `version-utils` with tests
Reviewed By: sota000
Differential Revision: D32556610
fbshipit-source-id: eb4ddc787498744156f985ab6d205c5d160e279b
Summary:
Changelog: [Internal] - Add getNextVersionFromTags to determine next release version off a release branch
In more detail - this work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
This function is later used in `prepare-package-for-release` script in D32556610 to bump the version
Reviewed By: cortinico, ShikaSD
Differential Revision: D32556609
fbshipit-source-id: 7d93ead0b34318a58ffeb876715fbd34d6041f4e
Summary:
Changelog: [Internal] Remove unnecessary logic and new parseVersions function
Changes:
* Remove `tagsForVersions` which in the past got all the tags for the `currentCommit` to figure out which one we're releasing to. I believe this is redundant because the CircleCI envvar `CIRCLE_TAG` should already have the version that we're releasing -- this is set in `bump-oss-version`. Note: this will only be set for full-on releases, (re: not nightly or commitly)
* Re-arrange some logic to group where we set `releaseVersion` and separate where we call `bump-oss-version` script for dryRun (commitly) && nightly builds
Reviewed By: hramos
Differential Revision: D32196237
fbshipit-source-id: 10f21f71bad1ea0496c5eb9094271cc4454a2544
Luna Wei
Lorenzo Sciandra
Riccardo Cipolleschi
Vincenzo Vitale
Luna Wei
Andres Suarez