System variables and Windows nightly installer change

image

image

Outcome: doesn’t work at all. I don’t know where it was installed; Program Files\KiCad has only the old 5.1.

Also the next one has the problem. r19930.7e58f1aa9f-x86_64-lite

Windows installer issues go here https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues

It has already been discussed in https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/98.

The latest nightly build works!

There was a small problem (which was probably related to the one mentioned by Seth above): I installed with the lite installer and left the 3d models uninstalled. The new path variables were added but the new 3d model path pointed to kicad\ folder instead of kicad\5.99. This means that if I wouldn’t have noticed it and installed the library later, KiCad 5.99 wouldn’t have found the library or would have found it in the wrong place.

Re-installing from scratch with all libraries (also deleting the old 5.99 user configuration from %appdata%\kicad\5.99) helped. I recommend that for easy transition. It takes care also of the library tables which was mentioned by chschlue above.

If you install 5.99 for the first time alongside 5.1 or start from scratch, remember to uncheck the “Import library configuration” option if you want to import 5.1 settings. Otherwise you’ll get the wrong library tables and may use 5.1 libraries with 5.99.

image

image

However, there’s still a problem with the 3D libraries: in old designs the footprints embedded into the board file refer to the old library path. You may need to add the old KISYS3DMOD variable and point it to the wanted 3D library folder. (I think this is why the original blog post announcement was taken down for a while. Let’s see what kind of instructions they’ll give us later.)

I just installed the latest Windows Nightly on a machine that has, and has only ever had, 5.1 installed on it. It all went well except that the Installer warned me that

image

That’s not strictly true as 5.99 isn’t installed and now goes into its own directory, so my existing 5.1 install shouldn’t be touched (and wasn’t).

I’m guessing this is just triggered by the presence of any version of KiCad, but is slightly worrying as this is supposed to allow for parallel installations.

A relatively minor detail, but one that probably aught to be corrected to stop any confusion.

@marekr, does your recent commit https://gitlab.com/kicad/packaging/kicad-win-builder/-/commit/f6156519edf27fcc3e34d55a6817d67ca73a8eb7 affect this or should @Chris_G report this in https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues ?

We’re trying to implement some way of fixing this automatically (in most cases) so that we don’t need to ask people to follow special instructions.

1 Like

Yes

The latest installer doesn’t warn anymore if the same x.y version isn’t installed.

Well it fixes the 5.1 and 5.99 conflict, the next 5.99 build will then warn about 5.99

Confirmed. Works as expected, thanks.

Right, which is to be expected isn’t it ?

IMO it’s expected that it warns about overwriting an existing installation. But there are many combinations. For example should the warning about re-installing exactly the same x.y.z version, overwriting same x.y version with a new x.y.z version and overwriting with a newer x.y version be different? Or should it have one message, always mentioning the old and new version strings?

This begs a more fundamental question. How will installs be handled in the future.

The current nightlies are enumerated as 5.99 so are now installed in …/kicad/5.99.

When 6.0 is released I’m guessing it will go into …/kicad/6.0. Will 6.0.1 go into …/kicad/6.0.1 or also into …/kicad/6.0 ?

How many folders are there going to be in the install directory, and how many application icons am I going to have, launching all these different versions ? I know I could just uninstall unwanted versions, but to do that every time a minor version update is released could get a bit boring.

Maybe I’m overthinking it :slight_smile:

it will go in 6.0 – our policy is that point releases like 6.0.1 should have compatible settings, etc and can overwrite the previous point release

6.1 then gets its own folder ? as it’s considered a major enough change ?

If we released a 6.1, then yes it would. It is more likely from the current plans that we will go from 6.0 to 7.0 (with 6.0.x bugfix releases)

OK, thanks for the explanation.