Sorry to drag this out again after having closed it, but I need to reopen it:
given i now have to backport parts of the fixes into the 3.0 branch I looked it up. IE support for edge will be eliminated by Microsoft by February 2023 Testing engines for older IE versions have been pulled, so I am basically not even able anymore to test for older browsers. (I have done most of the fixes the recent weeks on the "blind" by relying on personal knowledge and api googling) What is possible still until February 23... IE11 testing via Edge but that option then will be pulled as well. So again, how can we reliably support old browsers for the stable branches? I think TAs proposal is sound... use the reduced next codebase as common ground for all stable branches (which is the same as master anyway) ( which I today will run a test against what still is possible to test for) use the typescript based codebranch for the future 4.0 release. Everything else is just dragging around compatibility from my side for the sake of dragging it untested around, unless someone else can do some tests against this. Werner Am Mi., 14. Dez. 2022 um 07:51 Uhr schrieb Werner Punz < [email protected]>: > > 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 < > [email protected]>: > >> 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 <[email protected]> >> *Date: *Tuesday, December 13, 2022 at 2:13 PM >> *To: *MyFaces Development <[email protected]> >> *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 < >> [email protected]> 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 < >> [email protected]>: >> >> 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 < >> [email protected]>: >> >> 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 <[email protected]> >> 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 >> >> >> >> >> >> >> >>
