On 13-10-02 05:19 PM, Lex Trotman wrote:
All Developers,
Its time we deprecated windows support!!
The windows code in Geany is:
unmaintained and bit-rotting
buggy
holding us at an unreasonably old GTK version
hard to maintain due to being hacks on top of hacks
few of the developers have access to a representative development setup
(no WinXP on a VM is hardly representative)
Since there has never been a case of removing support for a platform before (that I know of) we don't have a process for doing it.
Therefore I propose that the windows version be deprecated, announcing it on the website, user ML and #geany startup message and anywhere else it might get through.
If this does not result in contributors who support the windows version coming forward and actually making a difference in the code and the user support then Windows should be dropped in a couple of versions.
I don't have any windows systems, don't use it and can't develop for it, but I have always noted when I was aware that some issue would impact the windows version, and have tried to help people who have had difficulties with Geany on windows where I could.
But I have run out of patience.
Heh, you're the only one with commit access that doesn't have at least a VM to test Windows stuff on :)
Anyway, I'm against removing Windows support, since a large portion of Geany's users (anecdotally, from IRC and bug tracker) are running Windows, but I am totally for:
- Removing buggy, non-trivial, non-maintained, win32-specific code (ie all of win32.[ch]). - Removing all #ifdef G_OS_WIN32 guards/blocks unless strictly required (since we're using G* we should need few if any such guards to be cross-platform). - Removing 2 of 3 build systems and using *one* that can compile Geany on all platforms (ex. fix Autotools to work in MSYS, or only using Waf, or maybe CMake or something else). - Having nightly/continuous build for Windows using above build system and environment, so non-Windows-using developers can know if they broke Windows build (IIUC current Win32 nightly builds using cross-compilation from Linux, completely separate from Win32 release build). Not sure this is possible unless we can run a VM on the server though. - Not officially caring about WinXP since it's hasn't "mainstream" support by Microsoft since 2009 (and is officially EOL next year). - Enabling GTK+3 support in Windows release and using latest supported GTK+ bundles provided by upstream, so were not fighting 5+ year old bugs that likely have been fixed since. - Not "working around" bugs in G* win32 stuff with #ifdef/win32.c hacks, but rather just filing a bug report upstream and pointing anyone hitting the bug to the upstream ticket. - Having a script and/or documentation on the Windows release/installer creation process so it can be updated and understood by all developers.
I think with most of the above it would alleviate the maintenance burden related to Win32 support.
Cheers, Matthew Brush