[Libusbx-devel] libusbx v1.0.9-rc5 is now available

[Pete Batard]

On 2012.04.01 16:38, Xiaofan Chen wrote:
>> Personally, I would really like to set a very clear and concise
>> official limit, such as "Anything older than X years or no longer
>> supported by the orignal manufacturer for backend Y, is not supported
>> by libusbx". Else, we're going to continue carry dead weight around
>> our neck and probably get into arguments of "but why are you guys
>> supporting X and not Z?". For instance, if we officially support
>> MSVC6, why shouldn't we support Win2k or any other technology that
>> came around the same time and that is long past EOL? From a logical
>> perspective, it doesn't make sense to support one and not the other.
>
> I would set X<=10.

That's quite large. If it was up to me, I'd set X<=3 for anything POSIX 
(Linux distros, MinGW and cygwin), as otherwise, I'm pretty sure it'll 
come bite us. Doesn't mean that anything older than 3 years is expected 
not to work, but I think it's fair to ask someone who is using a 
platform that they can (usually) upgrade for free to at least try to 
keep it relatively up to date. This is even more true as Peter and 
Daniel have previously taken the approach of not fixing issues related 
to usage of "older" tools and platforms, that we know how to work 
around, regardless of how recently the tool/platform was patched (or 
even whether if was fixed at all).

As far as I remember, we have the CKJ NLS issue for autotools, that 
hasn't been fixed for more than 12 or 18 months in an official release, 
we have the git eol=crlf bug that, also has been fixed for less than 18 
months, we have some missing prototypes on MinGW, that I think haven't 
been fixed for more than 12 months, and there's probably other stuff I 
don't remember and everything we're not yet aware of. In 2020, I'd 
prefer not having to remember that someone may hit the CJK NLS issue, 
which the autotools people fixed 9 years prior, because they are using a 
10 years old platform that we're still officially supporting.

However, I'd prefer leaving each platform maintainer to decide how far 
back they are want to support their relevant platforms/distros.

Now, with regards to MSVC, this is a bit more difficult, as it's a 
paying product so we can't exactly ask people to "just upgrade" (though 
the freely available WDK could be seen as a free upgrade path). But with 
WDK + MinGW (32+64) + cygwin, the best I can realistically see myself 
take on, as long as I remain the main Windows maintainer, is 3 versions 
of Visual Studio tops. This means that, as soon as Visual Studio 2012 is 
out, the only version of Visual Studio I'm planning to flag as 
officially supported in libusbx would be 2012, 2010 and 2008. So I guess 
that means 4 <= X <= 6 as far as MSVC is concerned...

> For Windows, maybe X=7 with XP 32bit to be the exception.

When it comes to OSes, as far as Windows is concerned, it's probably 
fair to try to go with the manufacturer's official EOL (and for 
non-Windows it might be too, but the large number of Linux distros may 
make such a choice a bit problematic on us).

By definition, someone who remains on an OS that is past EOL is making a 
deliberate choice of not being supported. As such, it wouldn't make much 
sense for us to taken on supporting them, even if there's still a 
significant volume of users.

Regards,

/Pete