devonfw ide does not show correct version after updating to 2022.12.001

[maybeec]

Expected behavior

As a user, I want to get the actual version by devonfw -v command so that I can report the version properly to my bug report.

Actual behavior

devon -v does not show the correct version number after upgrading to 2022.12.001 release:

Steps to reproduce (bug) / Use Case of feature request (enhancement)

1. Install 2022.08.002 devonfw ide
2. Update to 2022.12.001 version by devon ide update all

Related/Dependent Issues

Comments/Hints:

Affected version:

• OS: Windows 10
• Console: Git Bash

[hohwille]

At least to explain what you are observing:
You need to distinguish between the devonfw-ide installation and the devon command wrapper script.
You devonfw-ide installation has properly been updated and to get the "real" version you can simply do devon help and you will see the expected version.
However, the devon[.bat] wrapper script is not automatically overwritten on every update as usually this script does not change at all and it is "global" so reasonable changes here could cause compatibility problems so that we are also motivated to avoid them.

To address your actual concern:
IMHO the end-users expectation would be that devon -v would show the actual version of your devonfw-ide installation rather than the devon wrapper script. However, this can only work if you are inside a devonfw-ide installation (with your CWD) or have at least setup devonfw-ide from a devonfw-ide installation before calling it.
If that later is the case we could print the proper version. Maybe we can try to implement a trade-off and print both versions as available with reasonable context information so an end-user can understand everything.

[maybeec]

Sounds like a good tradeoff. I feel the explanation makes sense but is completely non transparent to users. Especially for debugging or bug reporting purposes, people like to know the current version they are working with.

[alfeilex]

While working on #971 I found out that after running devon ide update scripts the devon.bat of the previous version is copied to USERPROFILE/scripts. So if the updated IDE had version 2022.11.001 and I update, the copied devon.bat will contain the previous version and devon -v will return this previous version. Is this the right behavior? Maybe the cp commands should be executed after the update is complete?

ide/scripts/src/main/resources/scripts/command/ide

Lines 54 to 60 in 70baf93

	cp "${DEVON_IDE_HOME}/scripts/devon" ~/.devon/devon
	fi
	if doIsWindows
	then
	if [ "${target_version}" = "LATEST" ]
	then
	cp "${DEVON_IDE_HOME}/scripts/devon.bat" "${USERPROFILE}/scripts/devon.bat"

[hohwille]

While working on #971 I found out that after running devon ide update scripts the devon.bat of the previous version is copied to USERPROFILE/scripts. So if the updated IDE had version 2022.11.001 and I update, the copied devon.bat will contain the previous version and devon -v will return this previous version. Is this the right behavior? Maybe the cp commands should be executed after the update is complete?

ide/scripts/src/main/resources/scripts/command/ide

Lines 54 to 60 in 70baf93

	cp "${DEVON_IDE_HOME}/scripts/devon" ~/.devon/devon
	fi
	if doIsWindows
	then
	if [ "${target_version}" = "LATEST" ]
	then
	cp "${DEVON_IDE_HOME}/scripts/devon.bat" "${USERPROFILE}/scripts/devon.bat"

@alfeilex thanks for that analysis. This is indeed some kind of bug or undesired feature.
I guess a general problem is that we are obviously running the "old" version of the devon script to trigger the update. On windows this is causing issues with file locks as windows is locking the script while it is running so it cannot replace itself. As a workaround we do that asynchronously. Therefore, we cannot invoke the "fix" synchronously in this case.
The magic spots related to this can be found here:

ide/scripts/src/main/resources/scripts/functions

Line 834 in 70baf93

if [ "${2}" = "${DEVON_IDE_HOME}" ]

ide/scripts/src/main/resources/scripts/functions

Lines 777 to 779 in 70baf93

	if [ "${target}" = "${DEVON_IDE_HOME}/scripts" ] && doIsWindows
	then
	(sleep 10;doBackup "${target}" "${3}";doRunCommand "mv '${1}' '${target}'") &

[hohwille]

OK what @alfeilex has figured it is actually a different new bug. I have created issue #1312 for this.

[hohwille]

Comming back to the original problem that @maybeec reported and what I suggested earlier:

To address your actual concern:
IMHO the end-users expectation would be that devon -v would show the actual version of your devonfw-ide installation rather than the devon wrapper script. However, this can only work if you are inside a devonfw-ide installation (with your CWD) or have at least setup devonfw-ide from a devonfw-ide installation before calling it.
If that later is the case we could print the proper version. Maybe we can try to implement a trade-off and print both versions as available with reasonable context information so an end-user can understand everything.

A problem with this is the following:

ide/scripts/src/main/resources/scripts/command/ide

Line 181 in 153cebd

current_devon_version="$("${devon_cli}" -v)"

We can not change the behavior of devon[.bat] -v as suggested as this will break the above usage and cause incompatibility issues. We could change devon[.bat] --version but would this really help or cause even more confusion if we print something else as -v and --version are actually synonyms.
I would actually suggest to close this issue as wont fix:

• Workaround is to call devon help instead.
• We are on our way to create a new product out of devonfw-ide that tries to be as compatible as possible but gives us room to do some cleanup (see Migrate devonfw-ide from bash to Java with GraalVM #1090). The main idea is that the same settings git repository can be used both with devonfw-ide and the new product. Also the new product should behave very similar to the current devonfw-ide but be stripped from the term devonfw (so ~/.ide instead of ~/.devon, ide.properties instead of devon.properties, IDE_HOME instead of DEVON_IDE_HOME, ide as CLI entry point instead of devon and some slight facelift of the CLI API). In this new product we can simply solve this design flaw that we have made here.

[hohwille]

For the record: I just updated the help output to include:

 -v | --version         print the version of your devon script installed globally in your users home directory. This is not the version of your devonfw-ide installation that can be found above below the logo in green!