Heh, you're the only one with commit access that doesn't have at least a VM to test Windows stuff on :)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.
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
_______________________________________________