Improve consistency PR build numbers

[Borewit]

Aim of PR:

1. Build last commit of the Pull Request (PR)
2. Use consistent commit and commit distance throughout builds

Resolves #244

Changed the push trigger to build on last PR commit instead of the possible following merge commit.

[Borewit]

@touwys, can you review this PR?

• The versioning should be consistent.
• The commit hash should reflect the last commit hash of the branch a4b226e , which let version number end on "-ga4b226e"

[github-actions[bot]]

Build on PR #249 from commit a4b226e108791026442818a83e3ba90d59dfeb8f building: listFix() version: v2.9.0-18-ga4b226e in run 6961884382/1.

[Borewit]

Fine tuning the comment message another time...

[github-actions[bot]]

PR #249 building commit f23b53511b3a01e0fa98e9952db8fa2747136623: listFix() v2.9.0-18-gf23b535 in run 6961953948/1.

[touwys]

@Borewit

Power blackout due in 5 minutes Quickly:

1. Installed first, the binaries/portable app installation numbers appear to tally.

2. Executable install numbers are different. Screenshot below:

3. Executable grabbed app options/setting from the binary installation. Do they share?

[Borewit]

Seems you have an issue updating an existing installation with the installer.

I cannot reproduce it:

Probably best if you first uninstall, check if all installation files are gone, and then reinstall.

You are not able to detect if you are running a wrong version!

[touwys]

Probably best if you first uninstall, check if all installation files are gone, and then reinstall.

I did precisely that. Everything, including the registry entries, were properly cleared first, before installing the two builds.

You are not able to detect if you are running a wrong version!

I do not know what you mean by this.

•••

The only thing I can think of, as probable cause, is that there was, as it were, some "cross-talk" between the installer-version and the binary-version. I installed the latter version version first, and, as previously noted, these two versions share the same config files — and I do not know whether they are supposed to do that.

Next, I aim to start afresh again, but this time installing the exe-installer build first.

[touwys]

@Borewit

RETEST: listFix-windows-installer-exe-v2.9.0-18-ga4b226e

STEPS:

1. Cleanly remove the binary build. Screen video:

   Binary-build v2.9.0-18-ga4b226e — Improve consistency PR#249

2. Cleanly remove the installer-executable build. Screen video:

   Executable-build v2.9.0-18-ga4b226e — Improve consistency PR#249

3. Reinstall the installer-exe build, only. Issue fixed. Screenshot:

   

---

Additional comment:

1. Whatever the cause, it certainly looks like there is cross-contamination between the binary and executable builds when they are both installed.

2. The dot-prefix is dropped from the installation-folder title. Any particular reason for that? Screenshot:

   

[Borewit]

You are not able to detect if you are running a wrong version!

I do not know what you mean by this.

I wanted to say: you are now able to detect if you are running a wrong version!

[Borewit]

Whatever the cause, it certainly looks like there is cross-contamination between the binary and executable builds when they are both installed.

Not very likely. The only cause I can image is that something keeps the old installation file locked, causing processes to remove or replace old files to fail. Still strange that there is no error message. Unfortunately I cannot do much about this problem.

The "binary deployment", is strictly speaking not installed, it can be extracted, and you can run it. Call it a portable if you like.

the dot-prefix is dropped from the installation-folder title.

Not sure what you refer to. I see a folder named ".listFix()". I know we use that folder name to store configuration files in your home directory. The "." prefixed names are derived from Unix, where this is a hidden file or folder.

[touwys]

Not very likely. The only cause I can image is that something keeps the old installation file locked, causing processes to remove or replace old files to fail. Still strange that there is no error message. Unfortunately I cannot do much about this problem.

I have shown that whenever both the executable and the binary (portable) installations are deployed on the PC at the same time, they seem to share the same configuration files. It was shown that if one of these two is installed before the other, and gets configured, and the other gets installed subsequently, the latter is auto-electing for its use the configuration settings of the one that was installed first. Especially, this should not happen where the executable version is the one that gets installed first. Because, the portable version is supposed to be self-contained, and therefore should not have access to the whereabouts of configuration files beyond the boundaries of its own folder.

As far as the error message is concerned, is the rolling log file designed to capture something like that?

---

The "binary deployment", is strictly speaking not installed, it can be extracted, and you can run it. Call it a portable if you like.

That is my understanding, too, if you will. Furthermore, it is also my understanding that once the binary is executed, all the setup and config files gets extracted to a self-contained folder. Is this the correct assumption to make? In which case, also please refer to my first response, just above.

---

Not sure what you refer to. I see a folder named ".listFix()". I know we use that folder name to store configuration files in your home directory. The "." prefixed names are derived from Unix, where this is a hidden file or folder.

Sorry for not expressing the idea clearly. In fact, the dot is missing from the name of the build under review, and that was what I was getting at. The presented screenshot was snapped from a previous installation just to prove that, previously, the dot was in fact present — as it has always been ever since the very first review started. With the latest builds, the dot has disappeared altogether, for some reason. I was just curious why it was dropped, and if it perhaps could have any bearing on the issues we are discussing.

---

[Borewit]

You are getting into the weeds again @touwys, slowing down progress.

I have shown that whenever both the executable and the binary (portable) installations are deployed on the PC at the same time, they seem to share the same configuration files.

Indeed, as I already told you https://github.com/Borewit/listFix/pull/229#issuecomment-1816794604 they do share the same configuration, if you wish that to be changed, that discussion does not belong here.

Because, the portable version is supposed to be self-contained, and therefore should not have access to the whereabouts of configuration files beyond the boundaries of its own folder.

The binaries are now uploaded, which is the result PR https://github.com/Borewit/listFix/pull/241, the aim was not to have full blown portable version. That was to make it possible so that you could more easily switch between versions, with the caveat that config files are shared.

With the latest builds, the dot has disappeared altogether, for some reason. I was just curious why it was dropped, and if it perhaps could have any bearing on the issues we are discussing.

Still not clear to me where the . dropped. But it sounds like an improvement to me.

We do now have multiple PR's open, and feedback goes all directions, except any of the following:

• A confirmation the change is been implemented in line with the PR objectives (scope)
• Give me a valid reproducible argument why it is not

Then things stall.