Squirrel.windows: How to use multiple release "channels"?

Created on 12 Aug 2016  Â·  14Comments  Â·  Source: Squirrel/Squirrel.Windows

Hello,

I am new to Squirrel.Windows. I am implementing a Windows Forms application and I want to use Squirrel.Windows for the deployment using multiple release "channels". How can I accomplish this? Is there a guide with instructions on how to implement this feature? I have not found any information regarding this issue. The only thing that I found is that you need to create different folder and NuGet package for every channel, but how exactly you are using them?

Please, it is a very important issue. Thank you in advance.

Most helpful comment

To add to this, we use Octopus Deploy with Squirrel, to support these multiple channels and it works really well.

We have Octopus modify the app.config for what the release URL should be, and it works well.

Admittedly, this provides multiple installations of the application, but we actually want this behaviour.

All 14 comments

Please read through the other github issues where folks discuss this. You build your package for that "channel" and publish into that subfolder with the dedicated "RELEASES" file in the folder. Your application then needs to know the URLs to each of the folders which contains the RELEASES file, and you should be good to go (e.g. http://yourproduct.com/downloads/GA/; http://yourproduct.com/downloads/beta/; etc.)

Thank you.

This is all good, but are there any best pratices to make the app aware of which channel it was installed from?

I have previously made the distinction on build time, creating an appsettings key (.net WinForms) with the update url... but is this the best, or can the information be transfered on first-run/initial-install (is that information available?)

First of all, @dealproc thanks for the reply. I read through the other github issues as you suggested and as far as I can understand, the solution to this issue is to have multiple urls, one for every "channel" (i.e. the http://myserver.com/myproduct/Release is the url for the Release "channel", the http://myserver.com/myproduct/Beta is the url for the Beta "channel", etc.). I have some issues in this approach. To begin with, according to Squirrel documentation, the UpdateManager needs a url to point to. If we have multiple channels, how are we going to know in which channel each user is "subscribed"? Is there such an option in Squirrel, or not? Furthermore, if a user is "subscribed" in the Beta "channel", is there a way she gets the latest release from the Release "channel"? Do those "channels" communicate somehow through Squirrel? Thanks in advance.

@SissiKonsta yes, that would be the general idea how to create channels.
And there is no apparent way for a user to "upgrade" from beta to release, other than installing the app from the release channel, which leaves the user with two installed apps. 1 for beta and 1 for release. I can imagine building an upgrade scenario with the SquirrelAwareApp events.

And regarding the update url, in our instance we have created a application config settings which stores this, and this is per channel.

I am using a .NET winforms app, which has a settings concept. I think most application frameworks have a similar notion, otherwise creating such a setting should be straight forward.

Hopes this helps in understanding.

To add to this, we use Octopus Deploy with Squirrel, to support these multiple channels and it works really well.

We have Octopus modify the app.config for what the release URL should be, and it works well.

Admittedly, this provides multiple installations of the application, but we actually want this behaviour.

Thread dig. Wondering where @SissiKonsta and @dennismi ended up with this.

I do currently have a beta channel up, but I would like my users to be able to easily roll back to the most recent stable version (or even just access it via a shortcut) without knowing anything about squirrel's install locations whatsoever.

Was thinking about adding a little logic in the squirrel events to manually track and update a desktop shortcut for this. Wondering if any of you have tried similar.

Hi

I ended up publishing to each channel when ready, this allows for a test
version as well as a stable version to be installed side-by-side (given the
naming is different).

mvh
Dennis Micheelsen

On 4 January 2018 at 18:15, Jules PK Sound notifications@github.com wrote:

Thread dig. Wondering where @SissiKonsta https://github.com/sissikonsta
and @dennismi https://github.com/dennismi ended up with this.

I do currently have a beta channel up, but I would like my users to be
able to easily roll back to the most recent stable version (or even just
access it via a shortcut) without knowing anything about squirrel's install
locations whatsoever.

Was thinking about adding a little logic in the squirrel events to
manually track and update a desktop shortcut for this. Wondering if any of
you have tried similar.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Squirrel/Squirrel.Windows/issues/795#issuecomment-355342029,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAT8W7EpuMmmVqH9Ndv_LqJfp8l9PhRzks5tHQc7gaJpZM4Ji09L
.

The "given the naming is different" stipulation isn't attractive as fiddling with the assembly names on the build server makes my guts feel gross. It would be better if squirrel gave us the ability to specify postfixes for the install directories so this deployment concern could stay a deployment concern.

What I mean is, instead of only ever installing to %localappdata%// maybe squirrel could have a releasify option to define a channel postfix so the install location would be %localappdata%/-. Shortcuts would then inherit this postfix as well so a user could easily distinguish them on their desktop.

@paulcbetts thoughts?

Ooop, when re-reading the docs I came across the naming conventions page. https://github.com/Squirrel/Squirrel.Windows/blob/master/docs/using/naming.md

Gave taking advantage of those a shot, but now I seem to have an issue where the stub executable fails to launch the app. I'll start a new issue about it.

Wouldn't be viable strategy to have single channel and each release would be marked depending on it's channel? Then the client would decide which releases it wants to install or skip. This way, you can switch from beta into release just by switching release's tag. And it makes possible for client to move between channels on single installation.

But as Squirrel's default implementation doesn't support this, it would be necessary to implement client side specifically and have special "release tag" file, as I don't think RELEASES file supports custom tags.

@simquad

Can you please show a bit more detail on how did you achieve releasing for multiple channels (environments) using Octopus.

I use teamcity to build the project which builds the nuget package. Then use a separate teamcity project to push the package to Octopus using octopack step.

Now i need to run deploy project to deploy the setup on release publish area for UAT or PROD.

I need user to be able to run both UAT and PROD version simultaneously.

Can you please guide me on how to achieve this ?

Thanks

-Kalpesh

I also develop a multi-channel application and I need to be able to uninstall the previous channel after upgrading. Any pointers kindly appreciated.

@shiftkey original issue has been answered, this can be closed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dennisameling picture dennisameling  Â·  3Comments

Andrew-Hanlon picture Andrew-Hanlon  Â·  4Comments

Mzartek picture Mzartek  Â·  4Comments

joshiji picture joshiji  Â·  6Comments

CodeFunta picture CodeFunta  Â·  6Comments