Hi devs,
One of our users has recently reported this issue Loading... and also took the time to provide a PR for it avoid Promise.try usage by bfis · Pull Request #4376 · xwiki/xwiki-platform · GitHub . The problem is that our Browser Support Strategy doesn’t mention anything about Firefox ESR, which means it’s not supported currently, i.e. we don’t test XWiki with Firefox ESR, neither manually, nor automatically on our CI.
Given this, should we update our strategy to include Firefox ESR? I’m against it, but @MichaelHamann is for it. Pasting our discussion from #xwiki:
@MichaelHamann
I would prefer changing our support strategy to include the Firefox ESR version and to change the environments build to also test with the oldest supported ESR version as this seems to be the update strategy for the ESR version (they update to the new version when the x.3 release has been published, which is the same as when the previous ESR version becomes unsupported). To me, this would be consistent with how we support LTS versions of other software. In practice, this means that you can use features that have been out for at least 15 months, and in many cases that time interval is actually shorter.Actually, I might be wrong regarding when ESR branches become unsupported, but I think it would be reasonable to switch to a new LTS branch on the .3 release
See for the upgrade path documentation that mentions switching to the new ESR branch on the x.3 release: Firefox ESR release cycle | Firefox for Enterprise Help
@mflorea
I prefer we don’t support Firefox ESR because:
- adding a couple of more builds on CI (for each XWiki branch we support) would make it even slower than it is
- automated tests are not covering everything so we’d have to ask @ilie.andriuta to add Firefox ESR to his manual test suite, which, AFAIK, already takes a lot of time (even when doing only smoke tests), for all the XWiki branches we support
- not being able to use recent JavaScript APIs that are supported by stable versions of all major browsers is a big draw back for me
- it adds complications and possibly technical dept:
- you need to leave a comment (TODO) to simplify your code when we increase the supported ESR version
- we need to be notified when the oldest supported ESR version is increased in order to update our build and possibly our code
- do we handle ESR differently in XWiki LTS (e.g. 16.10.x) and latest stable (17.x)?
- it’s not obvious for me on Promise.try() - JavaScript | MDN and neither on JavaScript built-in: Promise: try | Can I use... Support tables for HTML5, CSS3, etc how do you know if an API is implemented by the “oldest supported ESR”. You have to check first on which version of Firefox this “oldest supported ESR” version is based, which is annoying, and easy to miss / forget
All this for what? Do we know how many users are using Firefox ESR? Based on Browser Market Share Worldwide | Statcounter Global Stats Firefox is 2.37%, so ESR must be way less. Sure, this stats may not reflect exactly XWiki usage, but still, I doubt ESR is used enough to be worth the cost it adds for us to support it.
@MichaelHamann
Regarding CI, my suggestion would have been that we change one of the two Firefox-based builds that we currently already have in the environment tests to use the ESR version. As it seems unlikely that old code behaves differently in the ESR version than the latest version and new code usually has good test coverage, I would have argued that it is enough to have automated tests and no manual tests.I agree that it seems difficult to find compatibility data for the ESR version, which seems surprising given that MDN is managed by Mozilla.
So it looks like Michael is +1 while I’m -0. What’s your position on this?
Thanks,
Marius