Re: Should We Start Dropping Windows XP Support?

[Ryan Lortie <desrt desrt ca>]

hi Fan Chun-wei,

On Tue, Dec 30, 2014, at 03:26, Fan Chun-wei wrote:
> -There are some things that required specialized implementations for XP, 
> for example, SRWLock in GLib and networking items in GIO, which may or 
> may not work well.
>   (for example, by using inet_pton() directly in ginetaddress.c for 
> Windows Vista and later enabled many of the network-address.c tests to
> pass)
> -We often needed to do GetProcAddress() to check the availability of 
> system-level funtionalities, which would probably need a clean-up.
> -As people may know, Microsoft ended support for XP this past April, and 
> it is found that maintaining support for XP is becoming a bigger and 
> bigger maintenance burden.
> -There is likely the need to move forward to use newer system APIs and 
> features, which were only available after XP (such as desktop/window 
> composition)
> -Other reasons that people might bring up for this.

Very well reasoned.

Among the reason above I'd also include the fallback path that we have
for monotonic time and secure random number generator seeding.

It's my opinion that we should drop XP support early next cycle and take
Vista with it.  That would mean that our minimum requirement would
become Windows 7.

Wikipedia seems like as good of a source for information as any:
http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm

My reason for thinking that is based on the fact that Vista is also out
of (mainstream) support and it's even less popular than XP.  I also make
a totally uninformed 'gut' guess that the people who are still running
XP are probably not the kind of people (by and large) who are into
installing new versions of software on their computers anyway (ie: they
won't be using the new versions of GLib and Gtk or any software that
packages them).

The only thing I have doubts about are the "server" OSes (ie: Windows
server 2003/2008).  I have no idea how popular these are and I suspect
that they would be unrepresented in any browser-based stats gathering
(aside from terminal servers).  I also expect that interest in running
Gtk-based software on these machines is perhaps lower, but the same
might not be true for GLib.  We may fine-tune our requirements for
"Windows 7 at minimum" to "Windows Server 2008 at minimum" depending on
the availability details of the APIs we actually want to use.  Let's
make that decision when we get there.  One thing worth noting is that
Server 2003 is out of extended support before the release date of GLib
2.46.0.  Windows 2008 will also be out of mainstream support.  It seems
less likely that a responsible admin would continue to use a server
product past its end of life than a normal user with a client OS.

If people are really interested in maintaining backwards compatibility
of their software to old releases they can make installer packages based
on older versions of GLib.

I already almost axed XP this cycle.  I think next cycle (released ~1.5
years after the end of super-extended-special support) is more than long
enough.  I also stress the fact that all already-released versions and
their stable branches (including 2.44) will continue to work for those
who want to package their software based on them for another couple of
years.

Cheers