-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Merge hotfix release/20.6.1
into current release/20.7
#17136
Conversation
- Point to build config field: JETPACK_POWERED_BOTTOM_SHEET - Uncomment the @feature annotation - Remove the @FeatureInDevelopment annotation - Remove comments and cleanup code
…elease_1.81.2 Integrate gutenberg-mobile release 1.81.2
…-jetpack-powered-bottom-sheet-feature-config [Hotfix] Show Jetpack Overlay only when the remote flag is enabled
Thanks for the ping, yes a |
You can test the WordPress changes on this Pull Request by downloading an installable build (wordpress-installable-build-pr17136-0b40fae.apk), or scanning this QR code: |
You can test the Jetpack changes on this Pull Request by downloading an installable build (jetpack-installable-build-pr17136-0b40fae.apk), or scanning this QR code: |
@AliSoftware It's unclear to me why we have If I look at the changelog of the hotfix PR the changeset is different and some updates are already in. Initially for that PR I created a branch on top of Aside from the unclear thingie, we should pick the first version, i.e. the one with the I'll investigate this further on a local merge attempt 👍 . |
There was a change that updated the same code in this PR: #17095 This change is part of Practically, this means none of the two options are correct because the code binding to the badge is different on the final code of the enclosing if (jetpackBrandingUtils.shouldShowJetpackBranding()) {
jetpackBadge.isVisible = true
if (jetpackBrandingUtils.shouldShowJetpackPoweredBottomSheet()) {
jetpackBadge.setOnClickListener {
jetpackBrandingUtils.trackBadgeTapped(ME)
viewModel.showJetpackPoweredBottomSheet()
}
}
} I'm not sure how we acting in such situations though. This code will only build when I've collected all changes in a merge example branch: |
Thanks @ovitrif for checking the conflict and @spencertransier for merging the branch to solve it and mark PR ready. I'm surprised though that the diff from 0b40fae (merge conflict resolution from @spencertransier ) does not contain all the same things as the comparison of the branch that @ovitrif created in merge/20.6.1-into-20.7...merge/20.6.1-into-20.7-me-fragment-conflict-fix — which also contains some changes in XML files as well in its diff. I'm not sure if it's just a GitHub glitch in what diff it's actually showing me in each case (and what branches they compare) and just because I'm looking at this from my phone and not digging too much in details so maybe it's just a red herring in practice… or if that's a genuine thing that got missed during the conflict resolution. My gut feeling would say it's the former (ie red herring and all is ok) — also because @ovitrif only mentioned |
Update: Thinking about it a bit more I think the layout and dimens XML I see in @ovitrif 's link are because it's comparing against the merge branch, while those xml changes are already in the release/20.7 branch so it's normal they don't appear in Spencer commits… strengthening my belief that my comment above is a red herring and result is all ok and as expected after all…? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for wrangling this @AliSoftware 🙇
I've tested the generated builds and the apps behave as expected. The code changes also look consistent to me and include all the changes from #17124 🎉
Note that the Gutenberg version upgrade is not included in this PR but this should be ok according to this comment.
Merging after @antonis' approval, despite the bit of back and forth on whether the diff is correct. From reading the conversation, I get the feeling that the diff is indeed correct. All in all, I think it's a safer bet to merge and unblock shipping a new build, rather than waiting any longer for additional confirmation, particularly because we haven't shipped a 20.7 beta yet and we're getting close to half-way through its code freeze cycle. |
That's true, my example branch was trying to make a buildable intermediate "version" of '20.6.1' that includes the code changes that led to the initial merge conflict; but in reality only the change from MeFragment was needed 👍, everything else was already there in 20.7 release branch. |
See rationale from #17136, namely: > We will pick the values from release/20.7 for now, but will have to > manually bump versionCode to 1269 (instead of the 1268 that our tooling > will bump from seeing 1267 in trunk) when we'll do the new beta once > this PR lands. > (There's no point in choosing versionCode=1268 or versionCode=1269 in > advance while resolving this conflict, because our tooling we update it > based on what's in trunk when we'll run fastlane new_beta_release…)
Merging
release/20.6.1
back intorelease/20.7
after doing a hotfix.The hotfix contained the following fixes:
TODO:
20.6.1
for review (once Play Store bug solved)MeFragment.kt
conflict) then undraft this PRversionCode
manually (see below)Conflict Resolution
MeFragment.kt
cc @ovitrif for confirming which resolution to pick for this conflict
build.gradle
We should pick the lines from
release/20.7
, but cc @geriux to double-check that av1.82.1
is in the works to include the bug fix (that landed in1.81.2
), and thatv1.82.1
will be shipped in a future beta of WP/JP Androidversion.properties
We will pick the values from
release/20.7
for now, but will have to manually bumpversionCode
to1269
(instead of the1268
that our tooling will bump from seeing1267
intrunk
) when we'll do the new beta once this PR lands.(There's no point in choosing
versionCode=1268
orversionCode=1269
in advance while resolving this conflict, because our tooling we update it based on what's intrunk
when we'll runfastlane new_beta_release
…)