Should {version} component be part of install path?

[ghost]

I was wondering what @Mpdreamz @russcam @urso @philkra think about including {version} component in path? I originally envisioned it to help with isolation and possibility of SxS install .. now I think this might pose a problem with version upgrades.

Current install paths:
Binaries: %ProgramFiles%\Elastic\{version}\Beats\{beat name}
Data: %ProgramData%\Elastic\{version}\Beats\{beat name}

Example:
C:\Program Files\Elastic\8.0.0\Beats\winlogbeat
C:\ProgramData\Elastic\8.0.0\Beats\winlogbeat

[Mpdreamz]

What scenario's do you see it possibly being a problem during version upgrades?

We started including version in the install path and that helped stabilize a whole bunch of issues during upgrades. Typically rogue untracked files being in the old directory preventing a proper cleanup.

Our folder structure was Elastic\{Product}\{Version} though

Elastic\{ProductSuite}\{Product}\{Version} to me looks better but I have little technical backing on that.

It'd be good to hash out Elastic\{ProductSuite}\{Product}\{Version} vs Elastic\{Version}\{ProductSuite}\{Product} to find out if it has technical implications over just being a stylistic choice.

[ghost]

I am leaning towards Elastic\{Version}\ because it's a major differentiatior in my head. All product suites and products have versions, not every version has a product, hence you can immediately tell which products are in which version.

What scenario's do you see it possibly being a problem during version upgrades?

Newer installer would have to know which version it upgrades to go and look into %ProgramData% to pickup customizations

[russcam]

Agree with @Mpdreamz - including version number in the install path alleviates issues in the way that installer engine tracks components during upgrades. We did experience an issue with the way that WixSharp assigns Component ids in the past that meant same named files in different directories in the hierarchy were assigned the same Component ID, and thus were seen as the same component during upgrades. This issue was fixed in the Elasticsearch installer.

It seems to be common practice to include the version number in the installation path e.g. SQL Server, JetBrains tools. This may be done to allow side-by-side version installs in these examples, so including now would not exclude this as an option in the future too.

I am leaning towards Elastic{Version}\

I quite like Elastic\{Product}\{Version} to group installs by product.

[ghost]

For the record I do like version in the path as well. This question was to establish consensus.

I am leaning towards Elastic{Version}\

I quite like Elastic{Product}{Version} to group installs by product.

I can flip this around, no problem.