I think we should just not touch the old code to much; its stable since like 10 years. Just touch 4.0 heavily to make it better for the future.
Am Mo., 19. Dez. 2022 um 15:41 Uhr schrieb Melloware <melloware...@gmail.com >: > My personal vote is to drop IE support anywhere it is.... > > > On 12/19/2022 5:37 AM, Werner Punz wrote: > > 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 < > werner.p...@gmail.com>: > >> >> 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 >>> >>> >>> >>> >>> >>> >>> >>>
