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

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: