Add documentation on the alternatives to the now deprecated side by side installations

[AdmiringWorm]

What New Or Updated Would You Like To See?

We need to add documentation for what alternatives exist and how to make use of these instead of the deprecated side by side installations.

Why Is It Needed?

As side by side installations are deprecated, alternatives to this feature need to be called out.

Additional Context?

One alternative I am aware of is to create specific packages when it is needed to be possible to have multiple versions of a software installed.

[xenon8]

As a licensed user, I am extremely worried about the change of removing side by side installations. We use this a lot in our deployments as our software supports side by side functionality between major releases. This may mean that we need to consider using Chocolatey as our deployment tool of choice for Windows packages.

[ckolumbus]

The concern I have is that not all packages are upgraded in time to honor the deprecation. There are several packages installed as side-by-side on my system because other packages have explicit references to concrete dependency packages.

Regarding the doc issue here it would be very important for me how I can deal with this situation.

[pauby]

@ckolumbus

The concern I have is that not all packages are upgraded in time to honor the deprecation

Do you mean that the packages are not upgraded in the Chocolatey Community Repository in time? Are you using Chocolatey CLI in an organizational context?

[ckolumbus]

@pauby Not yet ;-). I'm trying to convince my management to buy chocolatey as basis for our system provisioning and I use it for myself right now quite heavily. So up to now my main concern is: how can I maintain my personal machine in a proper state if there is no alternative way of dealing with packages that somehow "force" a version.

I did not want to say that I "expect" that every (open source ) maintainer should update their package. I'm honoring all the voluntary work and therefore I'm searching for help on how I can maintain my system despite the fact that not every packages will be update in time.

[romandolinsky]

I see posible issues with tools dependecy when is use version range.
Example:
Tool A have version from 1 till 10.
Tool B have have dependency: tool A version from 1 till 5. <dependency id="A" version=(1,5)/>
Tool C have dependency: tool A version from 6 till 10. <dependency id="A" version=(6,10)/>
With sxs I just install tool A in version 5 and 10 and tools B,C have fullfiled dependency ranges.
How solve mention case withou sxs ??

[pauby]

If you want software A to have both a version 1 to 5 and 6 to 10 installed on your system, then create two packages called (as suggestions) A-1 and A-6 and then take dependencies on those packages. There may be other ways to do this too. That is assuming of course that the underlying software will allow two versions to be installed (some will, some won't).

Note that your example is a very niche case. Any package manager will throw their hands up at those dependency versions as they are incompatible.

[pauby]

Once the documentation is updated, I'll add a link in this thread. We'd very much appreciate any feedback on those documents to allows us to update them based on your use cases.

[romandolinsky]

We are licensed users and we have own repos and own packages. All packages are able multiversion installation.
I only asking because with version in names we lose possibility specify range of supported version. For installing tool B is neccesary have A-1 or A-2 or A-3 ... or A-5. How now specifi these OR-s in package dependency when version is in id of packages? We don't wanna be fix to one specific version!
These are usually cases in multiple CI-s and in world where is neccesary test multiple versions.
I will wait for official documentations and maybe some examples.

[xenon8]

Any chance we can have a discussion about the proposed method of installing side by side? Because the current proposal is a nightmare for us. We heavily use the the side by side functionality to allow us to deploy minor versions of our software on the same box; infact across many boxes scaled out.

This allows for testing out different branches of the software in different scenarios. If I have create a new meta-version every time I do this, it would create a massive headache; this would cause changes to code in Puppet and nuspec, just to simply deploy new software out.

Can't you provide some method of how it worked previously?

[pauby]

@xenon8 As the issue is closed, the best place for this to be brought up would be a discussion.

When you do bring it up over there, can you indicate what you are looking for? Is the document update not enough? Are there areas missing from it? Once we have an understanding, we can raise a further issue to clarify the documentation if necessary.

[pauby]

The documentation for side-by-side installs has been updated. We would very much appreciate feedback on the documentation to see if we can make it clearer or clarify any areas. I have asked @xenon8 above to create a discussion based on their questions. If appropriate, you can add to that discussion or create a new discussion for feedback.

I'll go ahead and lock this thread now.