Conversation
rickvdl
left a comment
There was a problem hiding this comment.
This is great, AFAIK there shouldn't be any issues with this approach either, what do you think @RevenueCat/coresdk?
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
|
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:
|
|
@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 |
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 |
|
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 |
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.
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. |
|
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? |
|
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…
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 😅 |
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.