The main problem here is not that it's some arbitrary decision, but that it makes absolutely no sense to continue catering to this kernel version that is not in any way supported by anyone today and should be considered a hobbyist project for those who still want to run it. Catering to that would inherently mean NOT catering to the potential of later OS-es and I refuse to let an ancient, unsupported OS hold back development. Not only is it by now 5 years past its extended life cycle support by its vendor, it also builds on a completely unsupported version of the NT kernel (5.*) that is not only a different generation but does many critical things in a different way. You're absolutely correct i don't want to provide any support for Windows XP as an operating system any longer. Okay, I guess I need to (once again) clarify a few things here despite it already having been said many times. Why not join forces? Why do Pale Moon core devs maintain this kind of separation? Why can't core devs work together with Fedor2 and roytam1 to provide XP support? They have done an excellent job so far, maintaining their forks. So Fedor2's patches could be merged into UXP/PaleMoon/whatever or available on a different branch of a separate build for XP in the Pale Moon Git repo. Pale Moon used to have a separate XP build for Atom processors.

It's like Pale Moon developers were afraid of their browser known to be available for XP. The requirement for rebranding also seems excessive. If I'm correct, it seems illogical to refuse authorizing 3rd builds for XP because if we regard it as a different platform, then platform-specific issues should be dealt with by the maintainers (Fedor2 and roytam1).

html5 video).įor instance, what if there is an issue with CentOS 6's old kernel which is only patched by Red Hat and isn't available on other systems outside the RHEL world? Should it be fixed by Pale Moon core devs? Or should it be fixed by László Kovács, the maintainer for CentOS 6? I would think that it would be the task for the maintainer to provide a fix.

This will prevent intermixing XP specific issues with our own development, and prevent confusion about what is supported and what isn't (e.g.

Palemoon windows xp