How to organize the repo?

[hyochan]

I want to open up a discussion here today since we are trying on catching up our repo to recent Native updates (iOS storekit2 and playstore v5 migration).

Today, @andresesfm is working hard and there needs some consensus for other contributors to work together.

Here are some questions I've received and would like to share here.

1. Would it be possible to keep the new version 9.x into a branch, since it’s beta. It’s quite confusing to start breaking the old API codebase with new stuff still in beta?

   • @andresesfm I think we need to organize the next package again for maintaining beta. I think we can use the next package by publishing to next package. If you are fine with this decision, I'll work on this CI.

2. Do you have any way to organize the work on react-native-iap or it’s whoever can do whatever?

   • IMO, we try to embrace the changes as much as possible so it is always welcome to try new things. However, we might have opinions on the ideas given, so let's have some discussions.

Wrapping up, here I want to suggest on separating beta package to github package and release package to npm.
Please tell me how this sounds.

[jeremybarbet]

I also think we should be spending a bit more time on reviewing PRs. Absolutely no offence against people contributing to the repo, myself first, I am not aware of everything in depth in the project.

In my experience, when contributing for the first times, folks creating PRs are not aware of everything, (f.x. edges cases, specific APIs on different OS) that only a few maintainers are aware of. It would be great to do some extended testing when new PRs are coming in. A first step would be by running the example locally.

A better way could be by extending the example app, to use everything the API is exposing, so we catch more easily breaking changes: f.x.

• feat(ios-purchase): add appAccountToken to requestPurchase on iOS #1763
• Filtering subscriptions and iap products #1760

Another way would be to set e2e, with detox, for example. That would be ideal, but quite time consuming to set up. Maybe having a better example app would be an easier first step.

---

Any plan to reset force the head on main to keep v8 for now and move all the v9 work on next for the time being?

[andresesfm]

Hello @hyochan.

Thank you for bringing this up. I agree that we should've separated the beta into another branch. I tried to keep it backward- compatible so I assumed it would go a lot smoother. I have published beta4 that looks pretty stable and unless something goes wrong, I'll be promoting it to release candidate.

Moving forward, I like your idea of separating the branch. Thank you for laying the groundwork. I will follow those guidelines as I start working on StoreKit2.

Sorry for any inconvenience this might have caused.

[hyochan]

Hi @andresesfm.

I think you've not quite understood the progress here. Sorry for not providing enough information. I've just organized the next package in npm registry and you can see how it looks in below screenshot.

The strategy of CI is now like this.

1. When you want to publish to next package, just go to branch next in the github and get sourcecode in main branch. I just did rebasing.

   git checkout next
   git rebase main
   git push
   

   The above steps will run the CI for publishing the next package.

2. When you want to publish to latest package. You can create a new release as you've done before.

About reverting to 8.x

I'll handle your PR for reverting to version 8.x since I feel like you can get confused on maintaining next branch here which shouldn't be applied to next branch. After that, you can follow the progress on I've put up here. Hope this sounds clear to you.

Please tell me if you have any questions.

[hyochan]

@andresesfm @jeremybarbet

I have worked on CI/CD progress and here is the current status.

You can release the latest version by creating the release and you can release next version by updating the sourcecode in next branch.

You can read about this in my reply above.

Please feel free to give me any opinions.
Thanks.

[jeremybarbet]

I have a question regarding this kind of PR. The RNIapIosQueue was exposed as a public API. Let's say someone uses 8.5.1, then gets 8.5.2, the method doesn't exist anymore and user ends up with an error.

Ideally, that should have been tagged as breaking change, and move in 9.x or mark the RNIapIosQueue as deprecated and to be deleted in the next major version. Also breaking changes could be handle in bulk into a next branch (like it's done atm with v9) to avoid releasing too many major versions "in a row".

[andresesfm]

Hello @hyochan. I've looked at your changes and it makes sense to release from next for beta and follow the regular process for main. However, I'm. not convinced that auto-releasing from next is the best idea. We can use the same process as we do from main just selecting the next branch as described here: https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository (Step 6).

The reason why I don't think auto release is desirable is that many times we want to merge changes that don't include a change to package.json which creates a failure because it tries to upload to npm with the same version number.

Please let me know of your thoughts

[hyochan]

@andresesfm Thanks for your convincing thought. I definitely agree with your point!
I've managed to separate the releases just now.
You can now create a release with next branch to publish the next package.

Just keep in mind to change the two options above.

1. Target tag to next.
2. Check pre-release option.

[hyochan]

Also, I think it is better to organize the next repo separately from main without rebasing the whole thing. If we think something should be merged to next from main, we can cherry-pick the commit.

@andresesfm What do you think about this?

[hyochan]

@andresesfm Looks like next package has been accidentally released to latest.

3b7bc46#comments

I've just managed to fix these.
Hopefully, we won't have this problem again.

Please be cautious about merging branches to next. Let's try cherry-picking it instead.
Any suggestion on managing this would be appreciated either.

[andresesfm]

Thank you for fixing @hyochan

[hyochan]

Now the main and next branch shares the same CI.
#1859 is how I've done it.

You don't have to care about the CI now. The steps for publishing are the same as above!

[andresesfm]

@hyochan @jeremybarbet I want to bring to your attention that in my option, the ongoing updates from @jeremybarbet should be merged into main as they come and we can rev up sub-versions as we go. Whereas the Storekit 2 migration should be the one on next the reasons being that 1) it's more of a step-change 2) It will require people to move to ios 15 and 3) it will need multiple releases of beta builds for testing. Please let me know if you have any objections to this

[andresesfm]

This PR from next to main: #1881 will become 9.1.0

[jeremybarbet]

That's sounds good to me to merge next in main and continue the work in there 👍

However that should be release as v10 and not as a minor, most of the commits are breaking changes

[andresesfm]

@hyochan I just tried to publish a new alpha version using the same steps as before. But I noticed that it was published as latest instead of next which is not what we want of course. Can you please take a look?

[andresesfm]

@hyochan to mitigate I published 10.0.2 so it's not an immediate issue but I'll still need your help. For clarification I followed the provided steps as before: #1777 (comment)

Thank you