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
