Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add version bumpers for bare projects #9

Open
byCedric opened this issue Apr 19, 2020 · 3 comments · May be fixed by #17
Open

Add version bumpers for bare projects #9

byCedric opened this issue Apr 19, 2020 · 3 comments · May be fixed by #17

Comments

@byCedric
Copy link
Member

Description of the feature

Add version bumpers for bare projects to update e.g. versionCode in Gradle.

Motivation

It would be awesome if bare users can use this tool too!

Additional context

See this

@brettdh
Copy link

brettdh commented Sep 1, 2020

I'm getting close to the first release for my expo bare project and I'd like to start using standard-version before I do - so I'd love to contribute to addressing this gap.

My main question before I get started is whether bumpers for the xcode and gradle files are all that's needed here. I kind of want to zoom out a bit first and ask if you happen to know of (or have written! 🙂 ) 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.

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 think hearing your perspective on this might help me approach the problem more thoughtfully. I read your 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 you or someone must have thought of this already - so I'd love to hear what you think.

Thanks!

@brettdh
Copy link

brettdh commented Sep 8, 2020

@byCedric Since I made the above discussion a lot bigger than just this one issue, I've moved it here: https://forums.expo.io/t/how-to-handle-releases-and-changelogs-with-conventional-commits/42611

I'm about ready to start working on the native version bumpers described here; I'll ping you when I have a PR.

brettdh added a commit to brettdh/standard-version-expo that referenced this issue Sep 11, 2020
Adds app version and build number bumpers for the native iOS/Android
project configuration files (e.g. Info.plist, build.gradle).
These are usable by expo bare workflow projects, but also react-native
projects that don't use Expo, and even plain old iOS/Androd projects.

Closes expo-community#9.
@brettdh brettdh linked a pull request Sep 11, 2020 that will close this issue
brettdh added a commit to brettdh/standard-version-expo that referenced this issue Sep 11, 2020
Adds app version and build number bumpers for the native iOS/Android
project configuration files (e.g. Info.plist, build.gradle).
These are usable by expo bare workflow projects, but also react-native
projects that don't use Expo, and even plain old iOS/Android projects.

Closes expo-community#9.
@summerkiflain
Copy link

can we get #17 merged, need it urgently...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants