Bug(ios): Prerelease buildNumber option is not working

[hangai247]

Because of the following condition, ios buildNumber option is not working only strict is allowed.
https://github.com/alexandermendes/semantic-release-react-native/blob/master/src/version/ios.ts#L384-L385

[alexandermendes]

So that's saying that specifically a pre-release version will only work in strict mode, which could well be a mistake. Could you post your config as an example?

[hangai247]

{
  "branches": [
    "release",
    {
      "name": "develop",
      "prerelease": true
    }
  ],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "@semantic-release/changelog",
      {
        "changelogFile": "CHANGELOG.md"
      }
    ],
    [
      "@semantic-release/npm",
      {
        "npmPublish": false
      }
    ],
    [
      "semantic-release-react-native",
      {
        "versionStrategy": {
          "ios": {
            "buildNumber": "increment",
            "preRelease": true
          }
        }
      }
    ],
    [
      "@semantic-release/git",
      {
        "assets": [
          "ios/**/Info.plist",
          "ios/**/*.pbxproj",
          "android/app/build.gradle",
          "CHANGELOG.md",
          "package.json"
        ]
      }
    ],
    "@semantic-release/github"
  ]
}

[alexandermendes]

Ah, so looking back at the readme it seems this was intentional! https://github.com/alexandermendes/semantic-release-react-native#ios-1

[hangai247]

@alexandermendes I have tried using the default behavior but the iOS TestFlight upload is not working for the prereleases.
I am ending up with the buildNumber something like 1.1.1d2 1.1.6d4 or something like this
but Apple gives an error with a message of [Application Loader Error Output]: The provided entity includes an attribute with an invalid value n/a (ID: 23d48fd0-881a-4c5b-a8a1-57f4f0bb20e7)

[alexandermendes]

Hmm ok, I definitely have successfully used version numbers like this before. It's not obvious from that error that it's definitely the CFBundleVersion that's the problem. As you can see if you read my long explanation in the docs, Apple don't really provide great support for pre-release versioning. But suggestions for an alternative mechanism welcome 🤔

[brianjd]

I'm currently experiencing the same issue with TestFlight. In my case I have f in the suffix, which doesn't appear to be supported based on current docs.

While developing a new version of your app, you can include a suffix after the number that is being updated; for example 3.1.3a1. The character in the suffix represents the stage of development for the new version. For example, you can represent development, alpha, beta, and final candidate, by d, a, b, and fc. The final number in the suffix is the build version, which cannot be 0 and cannot exceed 255. When you release the new version of your app, remove the suffix.

Update:
I tested with b as the suffix character, that doesn't work either.

[mstrk]

Hey just shimming in because I'm also trying to get some semver through App Store Connect and I come to conclusion that they don’t/want to support it.

This is from an hold documentation:

While developing a new version of your app, you can include a suffix after the number that is being updated; for example 3.1.3a1. The character in the suffix represents the stage of development for the new version. For example, you can represent development, alpha, beta, and final candidate, by d, a, b, and fc. The final number in the suffix is the build version, which cannot be 0 and cannot exceed 255. When you release the new version of your app, remove the suffix.

The new documentation states the following here:

This key is a machine-readable string composed of one to three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0-9) and periods.

Each integer provides information about the build version in the format [Major].[Minor].[Patch]:

Major: A major revision number.

Minor: A minor revision number.

Patch: A maintenance release number.

You can include more integers but the system ignores them.

You can also abbreviate the build version by using only one or two integers, where missing integers in the format are interpreted as zeros. For example, 0 specifies 0.0.0, 10 specifies 10.0.0, and 10.5 specifies 10.5.0.

I used 4 integers separated by periods on the first release and it didn’t cause problems. The 4 period-separated integers appear on TestFlight, but any further archives just ignore changes past the 3rd integer .

It's a shame, but the best we can do is translate pre ids to some numbers on the CFBundleVersion within the 3 period-separated integers.

[alexandermendes]

I've killed this whole mechanism because yeah, it now seems there is no iOS support for pre-release versions.

f06b117

[alexandermendes]

And a further tweak in #10