Filepro Version 5.0.15

[Brian K. White]

----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Saturday, November 10, 2007 10:18 AM
Subject: Re: Filepro Version 5.0.15


> On Thu, Oct 25, 2007 at 07:35:59PM -0400, Brian K. White wrote:
>> Scott is 100% justified in feeling as though he's been slapped with an
>> unexpected and unecessary burden by fp. It's not reasonable to expect 
>> this
>> requirement to be trivial in all or most cases.
>
> I'm not entirely clear on why .15 required the oss... but I will say
> that I concur with Scott and Brian: I too believe it reasonable for an
> application not to require a OS patch for a point release, especially
> one that's a bugfix.  This is one of the reasons why release managers
> are expected to feature freeze older releases at some point: so that
> all later point releases *are* bugfix only release -- because I *don't*
> think it's unreasonable for feature releases to require such upgrade.
>
> But those should be 5.x upgrades, not 5.x.y upgrades.

I have to say that as one who compiles stuff on sco osr5 myself, I do know 
that this was probably just an unintended consequence of fp having their own 
build box being up to date.
It's hard to make an argument that fp should themselves use an obsolete 
platform to put out software that they then have to support and are somewhat 
liable for it's performance.

I was mostly concerned with the change in the way fp licenses are managed.

Now, if it turns out that the undesired new features require using abi/api 
that requires the later versions of the system libraries, and that merely 
recompiling the existing features would have resulted in a binary that 
didn't care if the system libraries were old or new, then we do have a 
problem.

But if even one little part of a bugfix, _to a preexisting feature_, 
required the new libraries (by say, using a function whos interface changed 
or which appeared new) then I can't fault fp for that.

However they should in that case make a big deal about it and warn people 
not to apply the update unless they can apply the os patch, provide 
streamlined help to get and apply the os patch (possibly they could include 
it on the cd and fp dowload page), and have the installer perform some test 
to avoid breaking an existing fp install by refusing to displace the working 
binaries with non-working ones.

Maybe it's not reasonable to be that careful for Linux, and so people who 
produce binaries for several platforms gradually forget that this is the 
standard SCO users expect and are used to enjoying and is a large part of 
why they use SCO despite it's many drawbacks.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!