[arachne] Re: Upgrading Arachne (was Re: I found it!!!)

Arachne at FreeLists---The Arachne Fan Club!

Hi Greg M.,
        I agree with you wholeheartedly on this
upgrading stuff.  I just did an install over my
existing installation and I can tell you that I
did not get the same result that I get if I do
an install into a new directory. So, if someone
doesn't know what the newest upgrade should
look like and how it is supposed to behave...
then...one wouldn't even know that something
was missing or behaving as not intended. The
only way someone would know that a problem 
existed is if it caused an error message or a
lockup, or some other major calamity. Many
lesser glitches could go un-noticed forever! <ggg>
Or, until someone else points them out as 
glitches, for example via The List. <ggg>
     BTW, if someone wants a bloated program
that tries to anticipate and handle every contingency
possible when doing an installation over an
existing installation, there are many available. <ggg>
However, I have yet to find even a bloated program
that works flawlessly and can handle every contingency! <ggg>
And none of them fit on a single floppy. <ggg>
And none of them run decently on my 386 or 486 or
even my older pentium. <ggg>

Eric        

On Thu, 11 May 2006 14:57:50 +1030 "Greg Mayman" <gmone@xxxxxxxxxx>
writes:
> Arachne at FreeLists---The Arachne Fan Club!
> 
> On Wed, 10 May 2006 11:41:55 +0000, Udo Kuhnt wrote:
> 
> > That is *exactly* what I want when I upgrade - I want to activate 
> new
> > features myself, preferably one by one, so I can test them 
> separately.
> 
> And so do I. But I also want to look at them working the way the
> developer intended, not modified or replaced by any of my own
> settings or additions.
> 
> So I start the new version in a separate directory, and only add
> or activate the various features when I'm sure what they are
> going to do and how they are going to do it.
> 
> >> Think about it: Why does the Arachne installer save old files in
> >> the backup directory when new ones are installed?
> 
> > Because the original developer was too lazy to write a routine to 
> merge
> > the new options into the old files? ;-)
> 
> So if you were a developer adding a new feature which the user
> has added as an external to the old version, how would you merge
> the files? Should a new feature take precedence over one that was
> added to the old version, or should the added one take
> precedence?
> 
> Or should this be a matter for the user to decide?
> 
> >> Surely that is because it is recognized that the new ones may
> >> work differently from the old ones, but the old ones may contain
> >> important stuff that the user may want to incorporate by hand
> >> into the new versions.
> 
> > Ah, so files like sign.txt, e-dress.txt and hotlist.htm work 
> differently
> > in every new version of Arachne! I did not know that.
> 
> And you didn't bother to read the words "may work differently" in
> my text, did you. I did _NOT_ say they would always work
> differently.
> 
> > You expect trouble, so you get it - that is your problem.
> 
> In my opinion it is better to avoid a problem than to try to fix
> it later.
> 
> Do you fill your car's fuel tank BEFORE you run out of fuel? Do
> you have the brakes checked BEFORE they fail?
> 
> > I just said
> > that it is a bad idea to make this appear a *necessary* procedure 
> to
> > upgrade Arachne.
> 
> I have just said that it is the way _I_ want to do it. And I also
> said that what I want to do does NOT make it necessary for anyone
> else to do it that way.
> 
> > Also, always trying to avoid problems that *might*
> > occur does not help to make Arachne a better piece of software.
> 
> Oh yes it does.
> 
> > Sometimes it would be better to see if there is actually an 
> obstacle
> > ahead before going a long way around it.
> 
> You don't have to run into a brick wall in your car to see a
> problem. And the way around a problem is no necessarily longer.
> 
> >> Some things may move across "one for one" into the new version,
> >> but not necessarily everything. Each one needs to be looked at
> >> individually and carefully to see that some new feature is not
> >> going to be compromised.
> 
> > From my experience, this seems to be the exception rather than the 
> rule.
> 
> Maybe you have been lucky.
> 
> > It seems to me that it is a much better way to simply upgrade 
> Arachne
> > and then see what (if anything) is missing than to deliberately 
> lose all
> > your settings because you are *afraid* of losing them. ;-)
> 
> LOSE ALL MY SETTINGS??????? What the %$#@ are you talking about?
> 
> Did I not make it clear to you that I install the new version
> into a directory that is COMPLETELY SEPARATE from the working
> copy of the old version?
> 
> That way I lose nothing!
> 
> I can work on the new version, setting the features just as I
> want, adding or removing externals as I want, until I am happy
> that it works the way I want, then I can make it my main working
> copy.
> 
> As I have already said, if anyone wants to jump straight into the
> new version of Arachne and use it, they can do exactly that!
> 
> Arachne allows it!
> 
> And if they want to take their time and customise the new version
> before they commit themselves fully to it, they can do that.
> 
> Arachne allows it!
> 
> That is the beauty of Arachne! It does NOT force you down one
> path or the other. The user can decide for him/her-self.

                  Arachne at FreeLists                  
-- Arachne, The Premier GPL Web Browser/Suite for DOS --

Other related posts: