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