add warning, if two different devon-ide are installed

[markusschuh]

As a devon user, I want a smooth as possible upgrade procedure, so that devon continues to work. Also, the devon ide should output better warnings, if I begin to leave the intended usage scope / upgrade path.

The following description is a bit outdated, since the former 3.0.0-beta2 potentially had still to many issues, to describe the current situation. I will try another such upgrade check later to verify, if it might work anyway better meanwhile. Nevertheless I assume, the main point I am missing, does not yet exist inside devon-ide-scripts-beta22:

I have setup a new devon-ide-scripts (3.0.0-beta22) on a macOS, where an older one (3.0.0-beta2) was already installed. The "setup" executed as expected, installing the default ide components inside the software sub directory of fresh chosen "DEVON_IDE_HOME". Just the files inside $HOME/.devon stayed untouched at the old version.

When I afterwards have opened another shell, switched to the new base dir and used devon, this produced a mix of "old script" and "components from new base dir" - which generates quite some error messages. Also, devon ide update failed to do anything useful - but that may mainly be caused, since the beta2 had issues - unresolved at that time.

Shouldn't the setup (or devon ide setup) at least warn, if there is an older version linked inside $HOME/.devon? I guess, I should have used anyway devon ide update. The setup could stop, when this is detected and require some additional "forced" argument - to be used by those, who know, what they are doing.

Affected version:

• OS: Windows/Linux/Mac? Tried on macOS 10.14.6 and also on Windows 10 in a similar (but not identical) setup with quite similar results.
• Former devon-ide: 3.0.0-beta2 / Newer devon-ide: 3.0.0-beta22

[markusschuh]

By the way: After the following procedure, everything worked as it should. But the casual user may need some more hint (output of setup) for that:

1. I have removed (moved away) the $HOME/.devondirectory
2. Switched to new DEVON_IDE_BASE
3. Run ./scripts/devon there

[hohwille]

See issue #269 - looks like a duplicate to me.
How recent/relevant is this issue?
Starting from e.g. beta22 onwards, can this error still be reproduced by upgrading to the latest version?
IMHO this is all stuff that has already been fixed.
If not, I would need more details to reproduce it. With #269 all my ways to reproduce the problem turned out to be related to far outdated versions of devon-ide. All versions before beta22 should be considered history. Once we have the official version out, we should not consider beta versions anymore at all. If we can reproduce this issue e.g. by installing beta22 and upgrading to beta23 then we need to trace down the error. Otherwise lets just close this issue and #269.

[markusschuh]

Yes, the #269 is a - kind of - duplicate of this idea for an enhancement. Also the majority of setup related issues here - newer than this #263 - IMHO had the same root causes ( #262 and #269, which now have been fixed). So any beta lower than beta24 should better be manually removed.
At least that seems to be true on Windows7 to Windows 10, when a "Git-for-Windows" v23.0 (or version near that)" is installed.

Could it be, you don't have a "Git-for-Windows" on your Windows 10 test VM? Or an older version? That would be my simplest explanation, why you commented here - and in some other issues - you could not reproduce the issues.

Anyway - I'll close this enhancement for this time. At the time of opening I was not yet sure, if there were a bug or just a problematic design. Now issues have been identified and resolved. Now I can concentrate on potential design flaws again - what needs some more review.

But I'm almost sure, I will open another enhancement issue when I have managed to retry the upgrade behavior with newer versions. I have a strong impression, the devon ide far too much relies on "side effects". E.g. you can run the "devon" script inside the scripts folder - and this already seems to be enough to replace files in home directory.

May look nice for many developers - but IMHO such side-effects have more disadvantages, than advantages. Sure - as long as the developer has executed the correct setup procedure before - and everything has been replaced as expected - the "side effect" is irrelevant. But the probability that something fails during setup seems high to me due to complex prerequisites. Therefore a few more checks and warning for unexpected components (like older versions first in PATH) looks still useful - if not necessary to me.

[markusschuh]

Closed, since much has been improved meanwhile. Needs re-analysis.