CocoaPods install fails on canary builds

[tom-un]

Issue

The canary builds published to npmjs.org are really usable because pod install always fails because CocoaPods cannot handle handle podspec files with version numbers that are start with all zeros 0.0.0.

The same issue exists upstreams for react-native: facebook#30036 (comment).

Whatever the solution, we want to be consistent with react-native and the other out-of-tree platforms (Windows).

One solution (as I described in the issue above) is to change the canary builds to use some non-zero version number like 1000.0.0. Another solution is to change the ruby scripts in all the .podspec's to use the commit hash alone as a version number when they see the package.json version starts with 0.0.0-.

[chrisglein]

Whatever the solution, we want to be consistent with react-native and the other out-of-tree platforms (Windows).

For what it's worth, I think we've also hit and had to workaround tooling issues related to the 0'd semver.

[alloy]

@chrisglein Got any links to issues/PRs that you could point me to?

[chrisglein]

@chrisglein Got any links to issues/PRs that you could point me to?

I was trying to come up with some issue/PR #s during triage and couldn't find any :(. Maybe @jonthysell or @NickGerleman might remember some?

[NickGerleman]

RNW stills uses 0.0.0-x for published NuGet and NPM packages. The issues I can think of were when tooling thought 0.0.0 builds were old versions, but we haven't seen too many major issues with it. We did see component governance think react 0.0.0-experimental.foo was old though, which was used in a couple of nightly RN builds.

I worry a bit that publishing 1000.0.0 builds could have the opposite problem, where tooling gets confused and points to them as latest. I rmemebr we've had issues with NuGet before doing things like that. There is precedence of FB using 1000.0.0 builds for local builds, but not anything published to my understanding.

[alloy]

In the realm of NPM there are dist-tags and CocoaPods treats any version with a hyphen as a prerelease. In both those cases these dependency managers should not ever select these versions over stable versions.

[NickGerleman]

Yeah, I think the case where I saw issues before was specifically around NuGet which IIRC doesn't interpret prerelease versions, and doesn't have the concept of the latest dist-tag. We tie NPM version to the version of the NuGet package we publish, but the NuGet package is generally not directly referenced too often, so the confusion would probably just be when going to NuGet.org to look at available packages and it showing the wrong thing for the latest published package.

Adding some more context, the upstream issue mentions RNW using 1000.0.0-canary.xxx which isn't quite correct. We went with 0.0.0-canary.xxx to align a bit more with React and React Native. I'm not familiar with how much effort the other solution would be around changing podspec files to use commit hash directly, but kind of like the idea of keeping 0.0.0 just for consistency with other projects.

[alloy]

I'm not familiar with how much effort the other solution would be around changing podspec files to use commit hash directly, but kind of like the idea of keeping 0.0.0 just for consistency with other projects.

It’s going to require a change to CocoaPods, but I don’t believe it’s a critical change. So I’ll take a look at that avenue now that it’s becoming clear that, from the perspective of consistency, that might be the easier path 👍

[alloy]

PR created CocoaPods/Core#657

[github-actions]

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.