> (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]
