You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2022/12/13 14:52:30 UTC
[VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
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
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Werner Punz <we...@gmail.com>.
Sorry to add something here. I mean I still can use the old codebase, but
everything I fix there I only can verify against newer browsers, with IE11
being the baseline and even that will be gone in 2 months!
Am Mo., 19. Dez. 2022 um 11:37 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> 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.punz@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 <pn...@gmail.com>
>>> *Date: *Tuesday, December 13, 2022 at 2:13 PM
>>> *To: *MyFaces Development <de...@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.thomas@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.punz@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 <
>>> pnicolucci@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 <we...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Werner Punz <we...@gmail.com>.
I merged now the changes into 2.3 basically 2.3 and 2.3-next share the same
code as well to some degree 3.0.
(I may will work also in an automated mechanism to switch namespaces like
we have it in the new codebase, so that all 3 branches share then really
the same code)
The thing is, the 2.3 code has not changed that much but some ie specific
code now has been moved as previously stated, into
the already existing shim layer (quirks classes)
That way we can theoretically re-add those shims into 2.3-next as well, but
practically I already have readded them to 3.x! We still
can remove them for 3 if anyone objects but then you will lose ie
compatibility.
To remove them you just have to remove the quirks classes from the assembly
xml files.
The good thing is, that all fixes except 4040 have now also made it into
3.0 that way. I will do the necessary backend fixes for MYFACES-4040
for the 3.0 branch tomorrow.
Am Di., 20. Dez. 2022 um 09:11 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> Never mind... I found another way... Which solves everything without too
> many code changes.
> To have a cleaner split between legacy and modern browsers I designed the
> old code around allowing extension classes to occupy the same namespace as
> the originals, replacing them. I used this mechanism for so called quirks
> classes which isolated IE specific code. This worked for most areas and
> made the 2.3-next code possible.
> This is kind of a shim mechanism without occupying the window namespace
> like normal shims do.
>
> In the end to clean up all this:
> I simply will move the code which made it in which is ie specific into
> specific quirks classes. That's a mechanism we have had for a ton of years
> but some newer fixes did not make it in yet.
> I also found old windows 8 vms lingering around on my nas so I still can
> test against the old ies.
> So what I am going to do is simply to move this specific code into the
> quirks part (it is mostly the head fix code anyway) and then I basically
> have mostly all branches in sync with the 2.3 branch just having the quirks
> classes on top.
>
> The main difference between 2.3 and 3.x is simply the namespaces of the
> request parameters, but I can cover that as well.
> But one thing after the other.
>
> So in the end it will be;
>
> 2.3 - 3.0 codebase based upon 2.3 with literally all legacy browser
> support in quirks mode classes in their own package. (I will if possible
> move the namespace specific handling into something similar I did for the
> next gen codebase, which also still supports the jsf namespace if wanted)
>
> 4.0 the typescript version.
>
> The changes in the 3.x codebase are relatively minor with some code being
> moved into the shim layer and some fixes coming in from the newer code
> levels, but thats about it.
>
> I think we can live with that.
>
> Ah yes, one thing I definitely want to break with is, ieMobile (WinMobile)
> and Blackberry (the really old ones)
>
> Our eval layer has been still supporting that. Since IE6 the eval method
> used literally by all browsers is to add elements to the head. In order to
> streamline the code I will drop the old eval code and unify on this method.
> (this removes some extra globalEval statements in the head change area,
> something which did not work on Blackberry properly to begin with anyway,
> due to browser bugs, and ieMobile from WinMobile had its fair share of
> problems as well being stuck on IE5 level!)
>
>
>
> Am Mo., 19. Dez. 2022 um 15:45 Uhr schrieb Thomas Andraschko <
> andraschko.thomas@gmail.com>:
>
>> 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 <
>> mellowaredev@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.punz@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 <pn...@gmail.com>
>>>>> *Date: *Tuesday, December 13, 2022 at 2:13 PM
>>>>> *To: *MyFaces Development <de...@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.thomas@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.punz@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 <
>>>>> pnicolucci@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 <we...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Werner Punz <we...@gmail.com>.
Never mind... I found another way... Which solves everything without too
many code changes.
To have a cleaner split between legacy and modern browsers I designed the
old code around allowing extension classes to occupy the same namespace as
the originals, replacing them. I used this mechanism for so called quirks
classes which isolated IE specific code. This worked for most areas and
made the 2.3-next code possible.
This is kind of a shim mechanism without occupying the window namespace
like normal shims do.
In the end to clean up all this:
I simply will move the code which made it in which is ie specific into
specific quirks classes. That's a mechanism we have had for a ton of years
but some newer fixes did not make it in yet.
I also found old windows 8 vms lingering around on my nas so I still can
test against the old ies.
So what I am going to do is simply to move this specific code into the
quirks part (it is mostly the head fix code anyway) and then I basically
have mostly all branches in sync with the 2.3 branch just having the quirks
classes on top.
The main difference between 2.3 and 3.x is simply the namespaces of the
request parameters, but I can cover that as well.
But one thing after the other.
So in the end it will be;
2.3 - 3.0 codebase based upon 2.3 with literally all legacy browser support
in quirks mode classes in their own package. (I will if possible move the
namespace specific handling into something similar I did for the next gen
codebase, which also still supports the jsf namespace if wanted)
4.0 the typescript version.
The changes in the 3.x codebase are relatively minor with some code being
moved into the shim layer and some fixes coming in from the newer code
levels, but thats about it.
I think we can live with that.
Ah yes, one thing I definitely want to break with is, ieMobile (WinMobile)
and Blackberry (the really old ones)
Our eval layer has been still supporting that. Since IE6 the eval method
used literally by all browsers is to add elements to the head. In order to
streamline the code I will drop the old eval code and unify on this method.
(this removes some extra globalEval statements in the head change area,
something which did not work on Blackberry properly to begin with anyway,
due to browser bugs, and ieMobile from WinMobile had its fair share of
problems as well being stuck on IE5 level!)
Am Mo., 19. Dez. 2022 um 15:45 Uhr schrieb Thomas Andraschko <
andraschko.thomas@gmail.com>:
> 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 <
> mellowaredev@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.punz@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 <pn...@gmail.com>
>>>> *Date: *Tuesday, December 13, 2022 at 2:13 PM
>>>> *To: *MyFaces Development <de...@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.thomas@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.punz@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 <
>>>> pnicolucci@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 <we...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Thomas Andraschko <an...@gmail.com>.
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 <mellowaredev@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.punz@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 <pn...@gmail.com>
>>> *Date: *Tuesday, December 13, 2022 at 2:13 PM
>>> *To: *MyFaces Development <de...@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.thomas@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.punz@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 <
>>> pnicolucci@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 <we...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Melloware <me...@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
> <we...@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 <de...@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 <pn...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 2:13 PM
> *To: *MyFaces Development <de...@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
> <an...@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
> <we...@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 <pn...@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
> <we...@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
>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Werner Punz <we...@gmail.com>.
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.punz@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 <pn...@gmail.com>
>> *Date: *Tuesday, December 13, 2022 at 2:13 PM
>> *To: *MyFaces Development <de...@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.thomas@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.punz@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 <
>> pnicolucci@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 <we...@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
>>
>>
>>
>>
>>
>>
>>
>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Werner Punz <we...@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 <pn...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 2:13 PM
> *To: *MyFaces Development <de...@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.thomas@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.punz@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 <
> pnicolucci@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 <we...@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
>
>
>
>
>
>
>
>
RE: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Volodymyr Siedlecki via dev <de...@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 <pn...@gmail.com>
Date: Tuesday, December 13, 2022 at 2:13 PM
To: MyFaces Development <de...@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 <an...@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 <we...@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 <pn...@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 <we...@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
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Paul Nicolucci <pn...@gmail.com>.
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.thomas@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.punz@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 <
>> pnicolucci@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 <we...@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
>>>>
>>>>
>>>>
>>>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Thomas Andraschko <an...@gmail.com>.
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.punz@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 <
> pnicolucci@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 <we...@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
>>>
>>>
>>>
>>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Werner Punz <we...@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 <
pnicolucci@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 <we...@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
>>
>>
>>
>>
Re: [VOTE] Informal vote: Merging 2.3-next jsf.jf into 2.3.x?
Posted by Paul Nicolucci <pn...@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 <we...@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
>
>
>
>