Renaming our nightly version

[lunaleaps]

Right now the react-native nightly is named like so:
0.0.0-20230413-2147-7d7f48da4 of the format 0.0.0-date-commit.

I'm wondering if we should instead name our nightlies to be more descriptive of the version they represent.

Proposing 0.73.0-nightly-date-commit

React does something like this for their next version. Checking with SemVer calculator, these nightly versions would be ignored in the ranges.

Part of the reason I'm proposing this is because we want to publish nightly versions of some of our other packages that react-native depends on. Having them all aligned like this would bring clarity to dealing with dependencies.

Thoughts?

[cipolleschi]

I think that one of the reasons why we didn't want to use that format is that, if for any kind of reasons, the suffixes are lost, we risk to release version 0.73.0 which is considered a stable and that could create trouble to various toolchains.

But a part for this constraints/extra care we should put into the scritps, I personally don't see other problems. I also like the fact that it will be closer to the RCs we actually release, closing a little bit the gap on the versions checks at least.

[lunaleaps]

How would the suffixes be lost? Wouldn't that be a problem with any npm package that uses this format, one example being React?

[cipolleschi]

mainly, human error. Imagine that we modify the script and we implement a wrong check somewhere and, as a result, we drop the suffix in the nightlies: if that happen, we risk to release a stable version instead of a nightly.

We had some version naming issue in the past, unfortunately, due to changes to the publishing script.

[NickGerleman]

Maybe we could add tests for this, if we are publishing to Verdaccio already? I.e. simulate the publish, then list the versions in the registry to sanity check it is in a form we expect?

[kelset]

A few thoughts:

1

"Checking with SemVer calculator, these nightly versions would be ignored in the ranges."

I'm not sure I follow what you mean, but if it's 0.73.0-nightly and we are working on the RC phase of 0.73, so something like 0.73.0-RC1, are you sure that npm will pick the right one (RC1) and not the most recent nightly?

2

Going for this 0.XX version would put more pressure in having the minor bumped in main branch to be done RIGHT AWAY after the cut of a branch. For context, for the bump to 0.73 it took weeks. If we had this pattern you are proposing around for the cut of 0.72, I'm pretty sure things would have ended up messy.

3

React also uses the 0.0.0 format for experimental, which is basically what nightlies are. Why can't we keep the 0.0.0 standard?

4

Part of the reason I'm proposing this is because we want to publish nightly versions of some of our other packages that react-native depends on. Having them all aligned like this would bring clarity to dealing with dependencies.

I'm not sure I'm following, how is 0.0.0 different from 0.73.0 to solve this? We need to change the version of all published packages anyway to match the nightly one.

[cortinico]

That's maybe something we want to align on between React and React Native then?

[lunaleaps]

Hm, we could call them canary. My only hesitation is that React has certain expectations on what that means which I'm not sure we're living up to -- so calling it the same might be mis-representing.

Another point is that we've already been referring to these releases as nightlies in our docs etc.
But in the end I don't feel super strongly, I think our users of nightlies are quite small

[NickGerleman]

You can also limit matches to nightlies for specific versions – ~0.73.0-nightly. That could be pretty useful for RN packages as well as external libraries. You can't do that with the existing 0.0.0-* versions

Semver compares prerelease segment alphanumerically, so specifying something like ~0.73.0-nightly would start to pull in RCs once those are out. Though maybe thats the intent if someone is manually wanting to test a specific version in development.

There is tooling out there which relies on the nightly dist-tag already, to pull latest builds, which I think might be more common.

[kelset]

Additionally, I think with nightly monorepo packages we wouldn't need to be publishing versions off main after we cut an RC.

I'm a bit lost. Aren't nightlies published automatically from main every 24hrs and that's like, their entire purpose? To be from main and to be automated?

let me try to clarify what I'm trying to say:

• currently, nightlies are published from main, which is versioned on 0.73 which is N+1 from the version we are working on.
• let's say we cut 73 branch tomorrow. That means that we publish a new 0.73 RC0 from 73-stable branch
• the nightly after this branch cut must be 0.74-nightly. And that means that main needs to be bumped to 0.74 ASAP after the branch cut.

[lunaleaps]

I'm a bit lost. Aren't nightlies published automatically from main every 24hrs and that's like, their entire purpose? To be from main and to be automated?

I'm not referring to nightlies here, I'm referring to how we publish monorepo packages today. For the example of 0.72, which is in current RC. When we cut 0.72 RC, we had to publish monorepo packages from main and we versioned them 0.73.0.

If we had monorepo nightlies, we won't have to do that anymore. On main, packages/react-native/package.json can point to "nightly" tags of its dependencies.

let me try to clarify what I'm trying to say:...
the nightly after this branch cut must be 0.74-nightly. And that means that main needs to be bumped to 0.74 ASAP after the branch cut.

I think your comment is about React Native nightly, while my original comment "...I think with nightly monorepo packages we wouldn't need to be publishing versions off main after we cut an RC." is talking about monorepo nightlies.

That may be the misunderstanding/confusing part -- sorry!

And yes in your example, after 0.73 is cut, the nightlies should be publishing at 0.74. I have a PR open that will do this: https://github.com/facebook/react-native/pull/37028/files#diff-782c2e5da18eb97e0360765721b89009f61fb604d2f23d15de8d5ba4a33d33adR52

[lunaleaps]

I'm going to go ahead with this change and re-name. I'll give a heads-up to Expo who I know is using it in their nightly CI

[lunaleaps]

We've renamed the react-native nightlies to the convention we've discussed. Closing!