Ok I will revert for now my 2.3 changes, given that no one (not really I am) wants to cut off old browser support in the old codebase, I will check if there is a way to get the head fix in without breaking compatibility to ie6...
The old codebase is basically just mostly the same, but a ton of browser hacks were simply cut. off for 2.3-next and 3.0. So I will stick with whatever we have for the respective branches then, which adds to some degree another layer of maintenance headaches.I am not 100% sure how far down the compatibility goes without the hacks, ie6 definitely is off the table given one hack is removed which fixes and ie6 mem leak but does not occur anymore on ie7! The most important part atm is to get the head fix back to ie6 levels. Thanks for the discussion. Am Mi., 14. Dez. 2022 um 03:33 Uhr schrieb Volodymyr Siedlecki via dev < dev@myfaces.apache.org>: > Hi, > > I agree with Paul. I would prefer not break any users -- we should keep > the older IE9 support in 2.3 / 3.0. > > Volodymyr > > > > *From: *Paul Nicolucci <pnicolu...@gmail.com> > *Date: *Tuesday, December 13, 2022 at 2:13 PM > *To: *MyFaces Development <dev@myfaces.apache.org> > *Subject: *[EXTERNAL] Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf > into 2.3.x? > > I agree with Thomas and I'll go further, I think we should only be doing > bug fixes in releases previous to the current 4. 0 release to avoid causing > any problems in versions of MyFaces already released and being used. For > example, removing > > ZjQcmQRYFpfptBannerStart > > *This Message Is From an Untrusted Sender * > > You have not previously corresponded with this sender. > > ZjQcmQRYFpfptBannerEnd > > I agree with Thomas and I'll go further, I think we should only be doing > bug fixes in releases previous to the current 4.0 release to avoid causing > any problems in versions of MyFaces already released and being used. For > example, removing browser support in 2.3/3.0 should be a no-go. > > > > Regards, > > > > Paul Nicolucci > > > > On Tue, Dec 13, 2022 at 10:22 AM Thomas Andraschko < > andraschko.tho...@gmail.com> wrote: > > IMO 2.3 and 2.3-next should be the same codebase and the old JS > > 3.0 should be the same too but with jakarta naming > > > > only 4.0 should should get the new typescript codebase > > > > Am Di., 13. Dez. 2022 um 16:14 Uhr schrieb Werner Punz < > werner.p...@gmail.com>: > > Yes I was a little bit too verbose, sorry about that. > > The proposal simply is to sync the jsf.js codebase between 2.3-next and > 2.3 so that they basically use the same js files. > > plus side less maintenance, downside, browser cutoff is ie9! So the jsf.js > from 2.3-next also should become the jsf.js codebase of 2.3.x > > > > > > > > Am Di., 13. Dez. 2022 um 16:07 Uhr schrieb Paul Nicolucci < > pnicolu...@gmail.com>: > > Hey Werner, > > > > To be complete here, what is the proposal for 3.0? > > > > Thanks, > > > > Paul Nicolucci > > > > On Tue, Dec 13, 2022 at 9:54 AM Werner Punz <werner.p...@gmail.com> wrote: > > Hello everyone, sorry for the informal vote, but Paul Nicolucci had the > idea. > > > > We had the discussion before, and no one really has objected, but I want > to vote on this. > > The issue is: > > We have divergent codebases for the jsf.js for 2.3 between next and 2.3.x > and 4.0 > > next was derived from 2.3 but got rid of tons of legacy code and hence > uplifted the browser baseline to IE9 atm. > > This is becoming a maintenance burden because I basically have to maintain > 4 different code branches for every fix. > > 2.3 > > 2.3-next > > 4.0 > > and 4.0 Typescript which will replace 4.0 hopefully soon. > > > > On top of that we have a ton of custom parameters I want to cut down like > expanded, complete at... which load different aspects of the build > > my goal is to have only development and production with development being > an uncompressed build and production being a compressed build. > > I18n also will be phased ont on the javascript side and an include of its > own (i18n is deprecated anyway, no one really used it to my knowledge and > the RI does > > not have it) > > > > The thing is I merged all this recently into 2.3 given that there was no > negative feedback, but I can revert this change easily. Given that > > 2.3 is a stable codebase, it is better to vote on this before either > keeping it that way or reverting it back. Some users might rely on older > browsers still > > and cutting them off from a stable branch might be a bad idea. > > > > So here is my Question > > > > Do we want this, less code on the jsf.js side, reduced configuration, but > also lifting the browser baseline and that in a stable branch? > > > > Yes or no? > > > > > > Please do a proper vote with +1 being YES, and -1 being NO! > > > > This is an informal vote, from my side! > > > > > > Werner > > > > > > > >
