At 11:58 AM 11/5/01 -0800, Jonathan Lundell wrote:
>Either too coarse or too fine, often enough, when we're talking about a
>semi-independent module. Consider, though, a more legitimate non-bloating
>use of a version field. Rather than try to support all versions, use it to
>determine whether the two ends of the communication channel are
>compatible, and fail gracefully because of the incompatible version. Tell
>the user to update the app, or whatever.
I have software out in the field that has been around for more than ten
years. Some of it has been maintenance-free (other than the
every-other-fortnight bug report that requires a fix) because the
underlying operating system didn't change. Some of it has been a
nightmare, requiring changes for each OS release and in some cases with
each sub-release in order to keep the feature bloat from knocking out the
functionality of the program.
Unlike many of you, my client base doesn't upgrade on a whim. They stick
with what works. That means all my software has to be able to run up and
down the version tree, and I have a real problem maintaining parallel
versions of code. In Linux, I have people on 2.0.34 still. I have people
running some of my software on old versions of Ultrix on hardware that
hasn't seen sales for over a decade. I just found out that software I
wrote 20 years ago is STILL in use, and customers were inquiring if I was
available to make changes!
And then there is the problem of who pays for my time to make the app
update. I don't charge people for updates as a rule -- that rule may have
to change for my Linux apps if this ill-thought-out idea goes into the
kernel. I expend enough effort trying to keep up with the crap coming out
of Redmond and Cupertino.
Apologies for the vent, but I just swatted another bug caused by an
undocumented change in Windows 2000 that nailed one of my apps but good. I
shudder to think what XP is going to look like when my clients start
thinking of "upgrading" their hardware and have XP foisted on them...
Satch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:27 EST