Invalid iOS buildNumber on alpha/beta releases

[AlbertoLopSie]

Hi Cedric,

I've just detected that when publishing a new release to an alpha branch, semantic release by default creates a version tag like 1.0.0-alpha.3 and semantic-release-expo copies that tag to the expo.version and expo.ios.buildNumber fields in App.json.

However, trying to publish an Expo project with a buildNumber lie that throws an error:

[19:44:04] Error: Problem validating fields in app.json. See https://docs.expo.io/versions/v35.0.0/workflow/configuration/
 [19:44:04]  • Field: ios.buildNumber - 'ios.buildNumber' should match pattern "^[A-Za-z0-9\.]+$".

The referred Expo documetation refers to an Apple developer doc explaining that the accepted form for a buildNumber like this should be something like 1.0.0a3

What would you suggest?

Changing the semantic-release-expo prepare.versions.ios lodash template? (my knowledge of lodash templates is close to none, could you suggest one?)

Changing the semantic-release tagFormat?

I would greatly appreciate your opinion/support on this.

[AlbertoLopSie]

Hi Cedric,

Getting crazy with prereleases here!!

Trying to generate a lodash template to generate Android/iOS versionCode/buildNumber that include prerelease info has been unsuccesfull so far.

Tons of test showed me that the SemVer 'next' variable in templates does not contain prerelease info at all.

A template like

ios: "${next} / ${next.version} / ${next.raw} / ${next.build.length} / ${next.prerelease.length}"  

generates

1.0.0 / 1.0.0 / 1.0.0 / 0 / 0

the strange thing is that 'recommended' generates "1.0.0-alpha.33" or so

For ios I've been able to extract the prerelease info right from the 'recommended' string (with some regexp), but for android that is an integer with no prerelease info of any kind.

PLEASE HELP!!

[melanger]

Hi @byCedric,

I would be also happy to have the prerelease info available for the Android version to be able to construct a different number.

I see that @AlbertoLopSie made a PR which replaces semver.coerce (#188).
Another possibility is to replace semver.coerce with semver.parse (and optionally semver.clean):

--- current version (semver.coerce)
+++ semver.clean + semver.parse
@@ -2,11 +2,11 @@
   options: {},
   loose: false,
   includePrerelease: false,
-  raw: '1.66.18',
+  raw: '1.66.18-alpha.6',
   major: 1,
   minor: 66,
   patch: 18,
-  prerelease: [],
+  prerelease: [ 'alpha', 6 ],
   build: [],
-  version: '1.66.18'
+  version: '1.66.18-alpha.6'
 }

As @AlbertoLopSie said, currently it is impossible to generate a new Android version number when only the prerelase part changes, because the prerelease info is not present in any of the available variables.

[melanger]

Also, the following lines of the README are untrue:

recommended version - The "raw" next release version (also available in `${next.raw}`)
recommended iOS buildNumber - The "raw" next release version (also available in `${next.raw}`)

because recommended is not coerced, so in the case of e.g. "1.66.18-alpha.6", recommended is "1.66.18-alpha.6" but next.raw is "1.66.18"

[melanger]

@byCedric Is there any chance this is going to be fixed? The fix may be as easy as replacing semver.coerce with semver.parse (see #185 (comment))

[elebioda]

Any update on this? Facing the same issue and having this resolved would remove such a headache.