Upgrade to latest... always! - was "Why?"

Sat Jul 3 06:04:49 PDT 2004

Well, I remember one upgrade that caused me to change hundreds of prc tables
because the "form" command was not working properly and I had to change
every one I had to "printer file" and then "form" and then, when Ken fixed
the problem (a couple of months later), I had to change all the tables again
back to plain "form" because the "printer file, form" version was not
printing the forms properly from the command promt.  So I'm a little shy
when upgrading to a later version.
I usually ask developers that I trust if it is worth while to upgrade and,
in this case, I've been told that if don't need the @id feature, to stay
put.
I'm _very_ happy with 05.0.09.  Except for some rare glitches, like the one
the "Why?" post was about, it has been just about perfect for me.

----- Original Message -----
From: "John Esak" <john at valar.com>
To: "Fplist (E-mail)" <filepro-list at seaslug.org>
Sent: Saturday, July 03, 2004 12:21 AM
Subject: Upgrade to latest... always! - was "Why?"

>
>
> I hate to add to this longggggggg thread... but I'll do it in this
> "top-post". Those who couldn't read some of the quoted text in this thread
> (and other threads as well) were experiencing only _slight_ trauma
compared
> to what my screen reader sounds like reading them... :-) I've also changed
> the topic to reflect what my comments are about.
>
> Just another exhortation to upgrade to the latest version of filePro you
are
> entitled to receive. Anything else is folly and short-sighted. I can name
at
> least 7 people who are _really_ unhappy because they did not upgrade their
> 4.8.x versions to the latest and greatest while they had the chance...
even
> those with 4.8.10 have some rather serious problems... Had they only
> obtained the 4.8.12 (and maybe even a couple higher) versions, they would
be
> much happier today. The very same goes for 5.0.x. Not wanting to upgrade
> because you think the latest version might harm your programming... well,
> like I said, folly and short-sighted. The newer versions of filePro only
fix
> bugs and add features. Your programming should not suffer _any_ ill
effects
> from upgrading. A possible (but desirable) exception is when, say a new
> environment variable is added to change the behavior of some condition
that
> was not working properly... or not a good _default_ behavior. These are
all
> noted clearly in the readme's of the upgrade release. I can remember
several
> times when such things broke my programs for a short while until I made
the
> corrections, but they have always been for the better. A couple examples I
> can remember are when an upgrade disallowed certain punctuation in labels.
> Or an even more important one where the upgrade made the consequence of
> pressing BREAK at an input question more predictable. Another was the
> ability to ignore the DKNF errors and not even display them...  All of
these
> upgrades made filePro more reliable and tightened up the processing one
> should use to make it work correctly. However, I have actually seen
> programming since these types of updates were made where the programmer
has
> chosen to include the environment variable to make filePro work in the
old,
> i.e., broken way, rather than just fix their process tables. Too bad, kind
> of a dumb thing to do in my opinion... but at least filePro usually (could
> probably even say always) gives the opportunity to maintain the
> "old/un-updated/broken" way of doing things with an environment variable.
> Sometimes the "old" way is not actually "broken", just not preferable. One
> environment variable that I remember changed the way -nl worked on lookups
> when retrieving its record if there was a group of records with the same
> key. One way (the old way retrieved the first record in the group. The new
> way retrieved the last record in the group. (Far more preferable if you
are
> trying to get the last record in an index.)  So the new way was chosen as
> the default operation and the environment variable was provided if your
> programming had been relying on it working in the "old" way.  Would anyone
> have wanted the old (not-so-good, not as preferable) way set as the
default
> just because it might have been used that way by programmers in the past?
> Not me, I'd rather be informed of the change and allowed to adjust my
> thinking and programming to the new/updated way. The environment variable
> might be nice for a short time to give me a chance to change the affected
> processing, but otherwise, moving on up is always my choice.
>
> I'm telling everyone here that the 5.0.13 release is pretty damn good...
> but, it certainly has many bugs and problems that will be (and are
already)
> fixed in what I suppose will be 5.0.14. Not getting that latest version
> would be a _real_ blunder... again, folly and short-sighted.  I do not
want
> to be in the boat of the people who do not have the latest and greatest
copy
> when the version level changes a couple times and this one is no longer
> supported, and the updates not available.  You can start and re-start the
> whole argument about what is and should be supported, but if FP Tech is
> going to do it the way they've stated... then there will not be any
> available 5.0.14's when 5.0.2 is released. If you are the type who does
not
> want to upgrade for _whatever_ reason you have, then you will be *stuck*
> with the version that you are so unhappy with now. :-)  In the face of how
> FP Tech is handling filePro versions and releases, the only thing anyone
> should do is upgrade as soon as new releases are ready.
>
> By the way. I don't understand the whole concept of not wanting to upgrade
> and couldn't adopt that position even if I wanted to do so. The support
> contracts we have with many vendors, some of them costing several thousand
> dollars a year, require that we abide by their "rules" and "procedures".
If
> we call to complain about a certain behavior, the support rep will go
> through the usual litany... "Do you have the latest version on your
system?"
> If not, they will lead you through the steps to get it on the system.
Then,
> and only the, if the problem still exists will it be assigned a tracking
> number and treated as an incident, etc. This is high-level, costly,
> professional support I'm talking about. They are tasked to solve the
> problems, period, and I don't mind following their procedures to get to
the
> bottom of any problem. I don't see why FP Tech should be asked to treat
any
> problem in some other way... at least not with their supported versions.
It
> is not to much to ask that the end-user be using the latest version of the
> program, in fact is is SOP _everywhere_.  If you don't believe this, try
the
> support teams even at places that don't charge for the support. Call UPS
and
> ask a question about World-Ship. If the first question out of the tech's
> mouth is not "What version are you running, please press Help/About..."
> I'll eat my words.
>
> Throwing in one more opinion. I do not believe any minor upgrade, i.e., an
> upgrade from 5.0.x to the latest 5.0.n version should cost any money...
and
> I don't think FP Tech charges for these... so there is really no good
reason
> not to upgrade as releases become available. As for moving up from 5.0.x
to
> 5.1.n. This will cost some money. It should. The features added in a major
> number change should warrant the charge and nobody should have any reason
to
> complain about this. As for moving from 5.x.n to 6.x.n, well, that should
> cost even more again.  And who would complain?  Not me.
>
> John Esak
>
>
>
> > -----Original Message-----
> > From: filepro-list-bounces at lists.celestial.com
> > [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Kenneth
> > Brody
> > Sent: Friday, July 02, 2004 2:39 PM
> > To: George Simon
> > Cc: filePro mailing list
> > Subject: Re: Why?
> >
> >
> > George Simon wrote:
> > [...]
> > > If they can't make it happen using rreport 5.0.13, we'll just
> > have to assume
> > > that it has been fixed.
> > [...]
> >
> > At which point, will you get the 5.0.13 update?
> >
> > --
> > +-------------------------+--------------------+------------------
> -----------+
> > | Kenneth J. Brody        | www.hvcomputer.com |
> >            |
> > | kenbrody at spamcop.net | www.fptech.com     | #include
> > <std_disclaimer.h> |
> > +-------------------------+--------------------+------------------
> -----------+
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>