[Geany-Devel] On Deprecation of Platforms

[Matthew Brush]

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