I’m getting close to the first release for my expo bare project and I’d like to start using standard-version (and, by implication, Conventional Commits) before I do. I’m wondering if anyone knows of a good resource regarding how semver even applies to Expo projects. I have a few initial thoughts, having no experience actually trying this out yet but just from intuition:
- Breaking changes mean a new app store version and a new Expo release channel.
- Non-breaking changes are just a new
expo publish
within the latest Expo release channel. - However, this seems to imply that only the major version matters for the app store releases, since minor and patch updates would be done as publishes within that major release’s Expo release channel.
- I could also see that there could be a bugfix in the shell app that didn’t require a new release channel.
So, I wrote down this initial strategy and started thinking through the implications:
- Any semver release is a new app store version
- Only major releases require a new expo release channel
- Any commit pushed in between releases can be a new bundle release without requiring a new semver (shell app) release
- Beta releases are simply new versions with a
x.y.z-beta.N
tag, whereN
is the build number.
But then this raises the question: if I’m using Conventional Commits to determine the semver release for the shell app, and the JS bundle releases are just versioned by their commit hash, how do I also use the commits to generate the changelog? A couple issues this raises:
- Changes are delivered in two ways:
- New app store releases
- OTA updates
- Each one could have its own changelog
- How can we separate which changes belong in which changelog?
- The
component
part of Conventional Commits would seem like a good fit - Perhaps that could be one component for the shell app, and other components for everything else?
- e.g.
fix(shell): update native library to fix bug #123
would go to the shell app’s changelog - but
feat(one)
andfix(two)
would go in the OTA updates changelog (assumingone
andtwo
are components defined for this app)
- e.g.
- This could work… but would the shell app release notes also include all the changes that were rolled out as OTA updates? I suppose I’d have the flexibility of filtering which commits appear in which changelog… but I’m not sure if that’s possible/simple to accomplish with existing tooling like standard-version.
- The
Since Expo apps have this inherent divide between one part (the shell app) that’s released more like an npm package and another part (the JS bundle) that’s released more continuously (within a release channel), I’m wondering where standard-version sits in a typical Expo-based release pipeline, with the considerations above in mind. I read this blog on the topic of standard-version-expo, but I didn’t notice anything about release channels.
Interestingly, this all applies just as well to managed-workflow projects; it’s just that the possible variety of breaking changes there is much smaller than in bare-workflow projects. This makes me even more certain that someone must have thought of this already - so I’d love to hear what folks think.
Thanks!