semantic-release-expo
semantic-release-expo copied to clipboard
fix: use semver constructor to create template variables supporting p…
…rereleases
Linked issue
Solves issue #185
Additional context
Using coerce() when building 'next' and 'last' template variables truncates all prerelease information contained in the version string turning all prerelease related SemVer fields useless when using those variables.
The suggested change only affects 'next' template variable construction (the only one I need) Please consider extending it to last if you find it useful.
Codecov Report
Merging #188 into develop will not change coverage. The diff coverage is
100.00%
.
@@ Coverage Diff @@
## develop #188 +/- ##
========================================
Coverage 94.96% 94.96%
========================================
Files 10 10
Lines 139 139
Branches 23 23
========================================
Hits 132 132
Misses 5 5
Partials 2 2
Impacted Files | Coverage Δ | |
---|---|---|
src/version.ts | 92.59% <100.00%> (ø) |
Thanks for the PR! I'll take a close look tomorrow ❤️ Maybe we need to update the last
semver too, if you do a new prerelease based on the old one?
Thanks for the PR! I'll take a close look tomorrow ❤️ Maybe we need to update the
last
semver too, if you do a new prerelease based on the old one?
I don't use the last
semver. Main use of the next
semver is to calculate iOS/Android buildNumbers that take the prerelease info account. Current ones does not.
BTW, in this process I've made some findings you may found useful:
According to Expo doc, the version
key in App.json is converted to CFBundleShortVersionString
while buildNumber ends into Info.plist as CFBundleVersion
Somewhere in the past, CFBundleVersion
supported strings like 1.2.5a12
to denote a 1.2.5-alpha.12
prerelease tag. But, at some point near year 2014 (or so) Apple changed that and CFBundleVersion
now only accept 3 dot-separated integers.
This lead me to have to invent a way to encode the prerelease info in a way similar to one used to make the Android versionCode
using the lodash templates your plugin provides.
The template I used for ios is:
ios: "${next.raw.replace(/(\\d*)\\.(\\d*)\\.(\\d*)(-(.*)\\.(.*))?/, (match, p1, p2, p3, p4, p5, p6) => [p1, String(100+Number(p2)).slice(-2), String(100+Number(p3)).slice(-2)].join('') + (typeof p4 === 'undefined' ? '.00000' : '.' + (10000 * (1 + 'abns'.indexOf(p5.charAt(0))) + Number(p6)))) }"
that generates a string like 010205.1012
, where 'alpha' generates 1012, beta 2012, next 3012 and staging '4012''
For Android I'm using:
android: "${next.raw.replace(/(\\d*)\\.(\\d*)\\.(\\d*)(-(.*)\\.(.*))?/, (match, p1, p2, p3, p4, p5, p6) => [p1, String(100+Number(p2)).slice(-2), String(100+Number(p3)).slice(-2)].join('') + (typeof p4 === 'undefined' ? '000' : (100 * (1 + 'abns'.indexOf(p5.charAt(0))) + Number(p6)))) }"
that generates a similar integer (with no decimal point) ignoring the expo SDK version (i don't really need it) like 102051012
I'm telling this because the way now you are computing the Android versionCode and ios buildNumber WILL NOT work with prereleases. Anyone needing to use them will have to use a custom template like mine.
Cheers!!
Wow, thanks for sharing! That's definitely useful 😄 Ok, so how about adding your method as a predefined version that you can use without doing the calculations yourself? Something like "precode", code with prerelease support? By making it available this way, it's backward compatible and you can have support for prereleases on ios and android. I'll try to make some time available this weekend to get started on this and merging your PR! Again, thanks for this ❤️
Glad to add my little grain of salt to your great dish, Cedric!
And your ‘precode’ idea sounds wonderful!!
Keep up the great work!
See U!!
Code Climate has analyzed commit a3e115bd and detected 0 issues on this pull request.
View more on Code Climate.
What is the status of this? is it doable?
This fixes probably all my problems :) What is the status?