I had different checksums than the release, this is why I wrote it on the vote thread. I would have never known, that my Mac produces different checksums than on Linux. Following Brians release guide on gist, a Discussion mail should be send for the final release pull request. After that ATR produces the vote mail. When a discussion appears for the release vote afterwards i would find it logically to answer to the vote thread when it’s related to the vote release.
> Am 05.06.2026 um 11:11 schrieb Niklas Merz <[email protected]>: > >> (and keep discussion on the DISCUSS thread) > > Is not part of the email template on ATR. We should probably add it > there as well. > > I also prefer having a discuss thread to keep things cleaner but I was > just replying in this case to keep the vote moving forward. > > On June 4, 2026, "[email protected]" <[email protected]> > wrote: >> Just playing devil's advocate here... >> >> But I don't think there is any particular Apache policy that said that >> we needed a VOTE and DISCUSS thread -- I think that was what we did >> historically just to keep the vote thread clean so that it is easy to >> tally up the vote counts. >> >> I didn't necessarily agree to change the process but maybe with ATR >> which I believe Apache tooling automatically keeps track of the >> binding >> votes maybe we can simplify into one email thread? >> >> Just a thought... >> >> On Thu, 2026-06-04 at 16:46 +0200, julio cesar sanchez wrote: >>> Shouldn’t the discussion on the vote thread be here? >>> >>> In the past I think the vote threads used to say something like >>> “please, >>> keep discussions in the discussion thread”, but it doesn’t say it, >> so >>> not >>> sure if the policy changed. >>> >>> El lunes, 25 de mayo de 2026, Manuel Beck >> <[email protected]> >>> escribió: >>> >>>> Hi Julio, >>>> >>>> I think you didn’t understand what I mean regarding the >>>> „configured“ >>>> statusbar. Before the statusbar of the Cordova app shined through >>>> the >>>> in-app bowser, because the in-app browser was constrained to the >>>> safe area >>>> top not the top edge. Now the in-app browser is constrained to the >>>> top >>>> edge, which overlays the statusbar of the app and makes the in-app >>>> browser >>>> fullscreen. I think the better approach is to let the statusbar >>>> shine >>>> through the in-app browser rather than overlaying it. It’s now the >>>> question >>>> if the in-app browser should be constrained to the top edge if no >>>> statusbar >>>> is visible or always be constrained to the top safe area, letting >>>> the >>>> statusbar part of the app always shine through. I think it’s the >>>> easiest >>>> and best way to let the statusbar part of the app shine through >> the >>>> in-app >>>> browser, which means, the in-app browser is always constrained to >>>> the top >>>> safe area, no matter how the statusbar is configured. >>>> >>>>> And for the version bump, I think it should be a major release >>>>> since >>>> there >>>>> are two commits with ! In the title. >>>>> >>>>> Funnily enough, one of them removes a method to check if >>>>> callbacks are >>>>> valid because it was unused. >>>> >>>> Wow, nice catch. I really oversaw the two commits with the !. It’s >>>> true >>>> that this requires a major. And you are correct, what Niklas added >>>> with >>>> "fix(ios): check callbackId with regex (#1152)“ was removed before >>>> by >>>> "chore(ios)!: Remove unused private method (#1113)“, really funny >>>> :) >>>> >>>>> Am 22.05.2026 um 14:35 schrieb julio cesar sanchez < >>>> [email protected]>: >>>>> >>>>> I don’t see that as a blocker, but it’s ok to wait if you think >>>>> you can >>>> fix >>>>> it soon. >>>>> >>>>> I have not used the plugin in a while, but in the past it didn’t >>>>> respect >>>>> the “configured” status bar color (I quote it because on iOS it >>>>> has not >>>>> been possible to style the bar since iOS 7, the status bar adds >> a >>>>> fake >>>> view >>>>> to simulate and style the status bar). >>>>> In app browser plugin used to have its one bar that had a solid >>>>> color and >>>>> not configurable. So even if that changed recently, I don’t see >>>>> it as >>>>> blocker. >>>>> >>>>> And for the version bump, I think it should be a major release >>>>> since >>>> there >>>>> are two commits with ! In the title. >>>>> >>>>> Funnily enough, one of them removes a method to check if >>>>> callbacks are >>>>> valid because it was unused. >>>>> >>>>> El El vie, 22 may 2026 a las 13:38, Manuel Beck >>>> <[email protected]> >>>>> escribió: >>>>> >>>>>> The InAppBrowser does currently ignore a configured statusbar, >>>>>> this has >>>> to >>>>>> be fixed, before a release can make. I will fix this the next >>>>>> days. >>>>>> Related issue: >>>>>> <https://github.com/apache/cordova-plugin- >> inappbrowser/issues/1155> >>>>>> >>>>>>> Am 20.05.2026 um 23:02 schrieb Norman Breau via dev < >>>>>> [email protected]>: >>>>>>> >>>>>>> I believe a minor release is fine... they appear to be all >>>>>>> fixes or >>>>>>> general improvements in a non-breaking way. >>>>>>> >>>>>>> The exception is >>>>>>> <https://github.com/apache/cordova-plugin- >> inappbrowser/pull/1107> >>>>>>> ) where >>>>>>> it was noted as a breaking change but it was decided to be >>>>>>> fine to be >>>>>>> merged for a minor release due to the circumstances >>>>>>> surrounding the >>>>>>> issue. >>>>>>> >>>>>>> On Wed, 2026-05-20 at 22:55 +0200, Niklas Merz wrote: >>>>>>>> Hej folks, >>>>>>>> >>>>>>>> as discussed before we would like to do a release for the >>>>>>>> IAB plugin. >>>>>>>> Should the next release be a major (7.0.0) or minor >> (6.1.0) >>>>>>>> release? >>>>>>>> The >>>>>>>> version in master is currently pinned to 6.1.0. >>>>>>>> >>>>>>>> We have quite a lot of changes since the last release 3 >>>>>>>> years ago. I >>>>>>>> see >>>>>>>> some deprecations and removal of old code. >>>>>>>> >>>>>>>> <<https://github.com/apache/cordova-plugin>- >>>>>>>> inappbrowser/compare/rel/6.0.0...master?expand=1> >>>>>>>> >>>>>>>> Any outstanding patches to land? >>>>>>>> >>>>>>>> Once we've decided on the release version Manuel and I >> will >>>>>>>> proceed >>>>>>>> with >>>>>>>> the release. >>>>>>>> >>>>>>>> Kind regards >>>>>>>> Niklas >>>>>>> >>>>>>> >> ------------------------------------------------------------- >>>>>>> -------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> ------------------------------------------------------------------- >>>> -- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected]
