Skip to content

Notify phc of new releases#6245

Open
vegaro wants to merge 1 commit intomainfrom
cesar/notify-phc
Open

Notify phc of new releases#6245
vegaro wants to merge 1 commit intomainfrom
cesar/notify-phc

Conversation

@vegaro
Copy link
Member

@vegaro vegaro commented Feb 11, 2026

Following what we do in phc to notify hybrids, I think we should notify phc when we release purchases-ios and purchases-android. Right now we automatically bump on Mondays, but now we are releasing phc more often and I don't see a problem on doing it on every release.

@vegaro vegaro requested a review from a team as a code owner February 11, 2026 16:52
Copy link
Member

@rickvdl rickvdl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, AFAIK there shouldn't be any issues with this approach either, what do you think @RevenueCat/coresdk?

@claude
Copy link

claude bot commented Feb 11, 2026

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

@tonidero
Copy link
Contributor

I think the only reason we used to have is to leave a week of "coolover" when a new native release happens before updating hybrid SDKs, in case of bad releases. If we do this, it will likely mean that we will be making new releases immediately/shortly after every native release, so any issues would be immediately exposed to all hybrids.

Having said that, I'm not too opposed to this, it might also get us closer to how a "monorepo" would work. A couple of thoughts:

  • This will mean that if for some reason one of the natives is delayed to release, we might continue to release PHC, then hybrids with only one of the natives. This is okish but might result in more hybrid releases...
  • One thought I had was to run this update one day after the native releases are supposed to go out, to try to minimize the changes of issues happening a bit. Maybe defeating the purpose of this PR though, since that would mean just a schedule change 🤔

@vegaro
Copy link
Member Author

vegaro commented Feb 11, 2026

@tonidero please note that this is just triggering the bump on the native dependencies in purchases-hybrid-common. It doesn't mean we have to release purchases-hybrid-common with the update, and we can always release purchases-hybrid-common without releasing the hybrids with the new phc version

@tonidero
Copy link
Contributor

It doesn't mean we have to release purchases-hybrid-common, and we can always release purchases-hybrid-common without releasing the hybrids

Hmm were you planning to change PHC to not auto release on merges to main? Otherwise, updating natives in PHC, basically mean immediately triggering a PHC update, which in turn triggers updates of PHC in hybrids.

Happy to rethink this entire flow though if we think we should accelerate it.... I do think leaving a bit of "test time" between natives and hybrids can be helpful some times, so that's why I'm unsure... but we can totally accelerate it

@vegaro
Copy link
Member Author

vegaro commented Feb 11, 2026

I see that for example if android releases first on wednesday, it's possible is released, and flutter updated and released that same day, without the week cooloff

Do we want the week cooloff though? I guess that's the question. Lately I see ourselves trying to propragate fixes to the hybrids as quick as possible and doing the android and ios releases earlier in the week becuase of that, so on wednesday the hybrids have the fixes

@tonidero
Copy link
Contributor

I see that for example if android releases first on wednesday, it's possible is released, and flutter updated and released that same day, without the week cooloff

Indeed... In reality, I think if we want to follow this path, we should just remove the schedules on hybrids, and just make any native releases trigger releases to all hybrids immediately.

Do we want the week cooloff though?

That's indeed the question... I think some cooloff could be good IMO... but maybe we could reduce it, from a week to a couple days, or maybe even one day? But well, it's true that I've also seen us accelerating releases quite often lately... I guess removing this cooloff entirely would be a point in favor of monorepo 😅...

My vote right now would be to leave maybe a day or two of cooloff instead... but not a strong opinion, if we think it's going to delay us, we can change to this "immediate" approach.

@vegaro
Copy link
Member Author

vegaro commented Feb 11, 2026

I was thinking about this a bit more... @tonidero with this new approach, if everything goes to plan, in theory we would have the one week cool off right? all sdks get triggered the release at the same time on Wednesdays. purchases-andoird and purchases-ios will trigger a phc update that won't make it to the hybrids until the next release.

Releases off schedule put the week cool off at risk, but don't we already have that issue?

@tonidero
Copy link
Contributor

You do have a point… that’s assuming that we don’t do the native release + phc release before finishing the hybrids releases. So basically we would have a bunch of prs and we would need to be mindful of the order we merge them a bit…
For example, on Wednesday, all releases are generated.

  • We start with natives that trigger a PHC release (we would need to fix it so if alo Android, iOS and web come right one after the other, the PR in PHC contains all updates).
  • The PHC release triggers updates in the hybrids. We merge those bumps.
  • Now we have the main branch in the hybrids contain different commits than the release
  • If for any reason the release PR needs to be remade, we would be including latest native releases

That’s admittedly an edge case. So normally we would indeed have a week cool off as long as we merge all release prs in order. Not sure will think on it and see what I think tomorrow 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants