Triplea: 6157 - install folder is no longer versioned

[DanVanAtta]

6157 on linux installed to a 'TripleA' folder instead of TripleA_1.9.0.0.6157. The version specific install folder was intentional to allow multiple versions to be installed "side-by-side".

Windows this has an additional implication since TripleA and triplea would be the same folder. That loses the split we had between the installation binaries and user saved content.

[DanVanAtta]

Confirming this is a regression, I did not want to uninstall 3635, if we lose the version number from the install folder then we go back to only having one version of the game at a time.

[ssoloff]

This was discussed in #2032. The reasoning was that the average user simply wants to upgrade versions, and that a side-by-side install is for devs and advanced users.

However, note that side-by-side installs are _not_ precluded in the current installer. You just have to manually change the install folder when prompted by the installer.

[Cernelius]

I confirm this, and I also guessed (correctly it seems) that you, for whatever reasons, made the change on purpose.
I agree that the old folder like "TripleA_1.9.0.0.3635" was preferable to the current just "TripleA" and suggest going back having a specific folder per version number.

However, note that side-by-side installs are not precluded in the current installer. You just have to manually change the install folder when prompted by the installer.

That is a bit annoying. But I get that only power users want to have multiple versions.

[DanVanAtta]

The version number for install folder was actually a requirement. When we went to 1.9 the old jar functionality was not going to work due to map differences, we needed a way to install 1.8 side by side. That is not strictly a requirement anymore if someone is upgrading from 1.9, but would be if upgrading from 1.8. Going forward we may hit the same limitation, we should evaluate carefully that we will not have the same problem going forward if we drop version numbers.

You just have to manually change the install folder when prompted by the installer.

Manually setting the version number I do not think is a real alternative, it should be baked into the path as an option.

[Cernelius]

My vote would be that I definitely prefer the folder being versioned, as I said.

[DanVanAtta]

Adding discussion label, I'd like us to revisit the decision for version numbers as it had a number of use-cases.

I could believe the majority use-case is to "just update" the game, but I am not necessarily convinced based on my own anecdotal experience. If we go that direction, some things to consider:

• we need to be sure the old-jar use cases are still okay. They may not be given map loading issues. Perhaps this is okay, but are we confident messaging is all updated and that we would not have the same problem going forward?
• we're happy with the upgrade and downgrade experience. If we remove files, will they be purged or will they become orphaned? What does downgrading look like? What happens to the 'user' content on upgrade and downgrade cases?
• we resolve the folder collision problem on Windows, ~/triplea and ~/TripleA would be the same folder. Is that actually okay?
• make it easy for testing.
  
  
  
  • These may be power users, but optimizing our ability to test is really important in my judgment. Our last 4 releases all had major problems, we need to really tighten up on that. I would put a lot of emphasis on an efficient testing processing, about as much emphasis as on the normal user experience (not to say we should trade one off against the other, but instead both should be really efficient and good, I don't think we can sacrifice either one).
  
  

[RoiEXLab]

A reason to stay with the non-version-number system is that config filee persist throughout versions: This includes the vmoptions file and the game_engine.properties file although it's relevance has decreased in the recent time.
As @ssoloff already mentioned: If a user wants to have a separate installation folder the user just has to select a radio button when running the installer and can call the folder TripleA-1.9 or whatever.
If you are however not convinced and believe we should go back to have version numbers, I'd suggest we only display version numbers of breaking changes, e.g. The minor version+build numbers should not be included into the folder name. Example: TripleA_1.9, TripleA_1.10, TripleA_2.0 or whatever

[ssoloff]

• we resolve the folder collision problem on Windows, ~/triplea and ~/TripleA would be the same folder. Is that actually okay?

The default installation folder on Windows is C:\Program Files\TripleA for 64-bit and C:\Program Files (x86)\TripleA for 32-bit. So, unless the user specifically chooses to install into their home directory, there shouldn't be a collision with the TripleA settings folder.

I guess the real question is, does the average Windows user change the default installation folder to install directly into their home directory?

[RoiEXLab]

@ssoloff unlikely, as I user I like to be able to spam the next button until everything is finished ^^
We could add a check to install4j to prevent such problems though

[ssoloff]

@RoiEXLab One thing that would be nice is if the Windows installation folder defaults to a location under the user's profile rather than a system-wide location since TripleA doesn't require admin rights. In other software I've used that doesn't require admin rights, the default installation location is usually under %LOCALAPPDATA%, which is typically something like C:\Users\Me\AppData\Local.

[RoiEXLab]

@ssoloff We might should offer two ways of installing TripleA. One way for all users which does require admin rights, and one way for a single user which doesn't

[DanVanAtta]

A reason to stay with the non-version-number system is that config file persist throughout versions

Is there a way for us to add or remove options to those files?

[DanVanAtta]

@ssoloff We might should offer two ways of installing TripleA. One way for all users which does require admin rights, and one way for a single user which doesn't

Why the two different ways? Why not just one? With two there is more variation we have to support, more things to explain to users, and they likely don't care and want to just spam click and play. We already have way too much explanatory text on how to do things that should be obvious. I'm not necessarily a fan of adding more ways to install and play the game.

[RoiEXLab]

@DanVanAtta install4j allows us to define how (and if) files should be overwritten.
In case of the vmoptions file there are five different modes to handle overwriting the file (I don't recall them exactly, but basically one is keeping the file, ine us replacing the file and one is asking the user what to do)

[DanVanAtta]

I'm most concerned that game_engine.properties be overwritten. IMO vm.properties is ideally deprecated in favor of the properties file.

[RoiEXLab]

The vmoptions file is for virtual machine options only, the options we can control from inside the game, the file we can use to "fix" the ipv6 issue some people have, so this file is competently unrelated to the game engine properties file

[DanVanAtta]

We should re-focus though back on whether to include the full version number in the install folder. That was done on purpose, it used to be that the install would re-use the same folder. Switching back may not be the best move. We unfortunately do not know what our user behavior is really going to be like.

@RoiEXLab @ssoloff , do you know offhand if the 1.8 folder location would now be the same as the new 1.9 folder location? Could those two be installed at the same time?

[RoiEXLab]

@DanVanAtta Is the 1.8 installer powered by install4j as well?
If so, the 2 versions can be installed side by side by changing the directory in the first installer screen. If not then maybe

[DanVanAtta]

Yes, install4j was introduced for 1.8.0.9 if not 1.8.0.7

It's a complication to instruct people to download 1.8 for those save games. In practice, I'm not sure how much of a problem it is anymore. It's a bigger complication to tell people to update the install directory.

The burden of cleaning up older installs is significant. This might be a topic we need to seek more opinions on, lobby players and forums.

[RoiEXLab]

This was the main intention behind this change: It annoyed me I had to uninstall old versions every time I installed a new version (especially if I had just created 3 different installers with minimal differences and needed to test a couple things)

[RoiEXLab]

@DanVanAtta Changing the installation directory is pretty self explanatory IMO. It's the first question the user is asked: "Do you want to update your existing installation?"
Just try it yourself, most of the users do not have a need for parallel installs anyway.

[DanVanAtta]

Changing the installation directory is pretty self explanatory IMO

It is, but you are now hand managing multiple versions when before the location and naming were automatic. I agree most users do not need this, but for those that found it useful - it is a downgrade.

most of the users do not have a need for parallel installs anyway

Now that 1.8 is quite far in the rear-view mirror, I agree. Going forward, it depends on how we replace the old jar functionality and if we ever break that functionality again. But if needed, we very well could start adding a major version when we cross that bridge, we are not locked out of options.

Given that, keeping the current configuration seems optimal. (I suspect though we need to start doing more testing ourselves, without some dogfooding I wonder if that process might get to be really painful)

[DanVanAtta]

@RoiEXLab does the game_engine.properties file and vm.options property files update? We need that to be the case, it's a bad bug otherwise since the game engine version would not change!

[RoiEXLab]

@DanVanAtta They are supposed to (unless install4j is buggy), the overwrite mode is set to 4 which means replace always as I suppose (if this is not the case the installer would replace none of the files including the jar file).
For the vmoptions file I chose update if newer, otherwise ask. (Although this is not really necessary as JVM options don't change very often).
Here you can see all of the different Overwrite modes (without numbers): Install4j Javadocs
If something is not like you'd want it to be you can change it in the install4j file

[Cernelius]

I believe you should remove the "regression" label.

[RoiEXLab]

Doesn't really matter, because this issue is closed, but if this makes you sleep bad...

[Cernelius]

Thanks.