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

[Xiaofan Chen]

On Tue, Apr 3, 2012 at 2:50 AM, Pete Batard <pete at akeo.ie> wrote:
> 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).

I mentioned X<=10 is to set 10 as the absolute maximum (with Windows
XP OS support to be the exception). Since I also mentioned the following,
you can see I was really suggesting X=7 for OS with XP to be the
exception.
>> For Windows, maybe X=7 with XP 32bit to be the exception.
>> For Linux, maybe X=7 is good enough. Probably same
>> for Mac OS X. I can only test Mac OS X Lion myself.
>> I am able to test Windows XP onwards and Linux
>> as older as Ubuntu 8.04 (2008). But I will try installing older
>> Debian 3.1 which was released back in 2005.

But you have a good point with regard to toolchain. X=3 is fine for
me for MinGW (MinGW.org and MinGW-w64) and Cygwin.

And you are also right for Linux distros probably X=3 (I would suggest X=3+1
since there is some kind of transition in between) is good enough since most
of the Linux distros are not supported longer than that (Ubuntu LTS is usually
3 years). The Enterprise Linux vendors (Redhat, Suse, Oracle, etc) anyway
will maintain their own distros even though their life cycle can be greater than
3 years.

However, there are too many Linux distros out there. So I think it is
not good to use the distros as a gauge, rather we should use Linux kernel
versions, and set X=4 (2.6.24?) is good enough. But I'd like to
see 2.6.18 (2006) to be officially supported as well (RHEL 5 is using
2.6.18). I myself always use cutting edge Linux versions (usually
latest Ubuntu LTS and latest Ubuntu distro, and Arch Linux as a
secondary choice). I also always use the latest Windows version
myself and sometime a version older. Right now I only run
Windows 7 at home (with some VMs purely for

How about Mac OS X? It is Posix but it is also a paid OS like
Windows. I am not so sure about Apple's policy about OS
product life cycle?

> 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.

Supposedly you are the Windows maintainer. Hans and Ludovic
can be the Linux maintainer. Who represents Mac OS X before
Nathan comes on board?

I am rather OS neutral but I can not be a maintainer since I
can not code. I will serve more as a tester and support role.

> 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...

I agree.

>> 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).

Okay. I am not so sure about Apple's policy about Mac OS X's product
life cycle or official support policy.

> 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.
>

I agree.

-- 
Xiaofan