Squirrel.windows: Rollback strategy

[grandtiger]

What's the recommended strategy for rollback? Ideally, rollback should be achieve by rollback the folder / URL that contains all the binaries (Setup.msi, Setup.exe, RELEASES, xxxx-delta-nupkg, xxxx-full.nupkg) to the previous state. Is this possible? If not, is there any plan to introduce support for rollback?

[anaisbetts]

What do you mean by 'rollback' - do you mean from a developer perspective? Or from a user failed-install perspective?

[bengotow]

This may not be related, but I was just going to file a similar ticket: I've noticed that we're unable to get Squirrel.Windows to move to older versions. eg: if the app has the version number 0.3.32 and we send it a RELEASES file with the following content:

C1589D46DB2C1BECF4363DD14ED0C2A4C5420A0A nylas-0.3.29-full.nupkg 86917771

It downloads the nupkg, unpacks it, and then deletes it, relaunching the pre-existing version. We're able to roll back to previous releases with Squirrel.Mac (which I don't think parses the version numbers). Would be really great if the same thing worked on Windows!

(Sidenote: most recently, we've wanted this so that users who subscribe to the beta update channel can move back to the stable channel.)

[anaisbetts]

@bengotow I might try to support it but it's this massive special-case everywhere (i.e. delta logic gets weird, etc etc). Easier thing at the moment is to just create a rollback package that has a higher version #

[SartorialOffense]

The reason I would push for this to be added is being able to create "channels" for Test, Dev, Prod without having separate installs for each.

[anaisbetts]

@trumbjd You can totally do this already via just changing the URL. All you need to do is make sure your version number is consistent between the different channels (i.e. always increasing)

[SartorialOffense]

That is super. I must have missed this when I did an eval last year. Appreciate the correction!

[raybooysen]

This is pretty important for my project. If we roll-out a buggy version, it would be nice to easily roll-back to a previous package by modifying the RELEASES file instead of rolling forward.

Rolling forward is generally a longer process (builds, etc.) and for a buggy release, moving quickly is better for our clients.

[fleischman718]

Same here.
This is a killer feature for me, I'm still stuck with default publish because i must have an easy way to roll back a bad build.

[fredrik--johansson]

Any news regarding this?

I would love to be able to automatically downgrade my users installed version.

My current strategy of reverting the faulty commit, build, and increase the version number is not ideal.

[alfequilu]

Same question, need to be able to rollback a buggy release fast and easy. Any news about this?

[gv126ck]

As a side not, what I have discovered by chance was when I created a beta version that had a build that was 0.6.4 and the existing Prod version was 0.6.5, if you run the setup for the app which kept the same name and paths for the prod version it actually removed the prod version 0.6.5 and now the local userdata folder starts with the 0.6.4 version.
I too was wondering about the rollback but this side effect could be used to eliminate the bad build by re-running the setup and the higher version numbered release gets blown away...

[vadian]

This is a major issue for me as well. We're looking to integrate Octopus and Squirrel as a replacement for our home-rolled updater process. What we would like is the ability to one-button rollback via Octopus in the same manner that we can rollback our server side applications.

[hs-hub-world]

+1 for me.

[tafs7]

any comments/updates on this request? @paulcbetts

[hs-hub-world]

Hi Everyone. Actually, I have implemented a rollback feature and it works great. I am just doing little more thorough testing then I'll ask the team to review it and hopefully we can get a pull request going.
And of course, I'll document how it works.

[SartorialOffense]

Excellent, can't wait to see it!

On Mon, Jun 26, 2017 at 2:45 PM, hs-hub-world [e-mail]
wrote:

Hi Everyone. Actually, I have implemented a rollback feature and it works
great. I am just doing little more thorough testing then I'll ask the team
to review it and hopefully we can get a pull request going.
And of course, I'll document how it works.

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

[BethanyBerkowitz]

@hs-hub-world Looking forward to your rollback feature! We want users to be able to switch back and forth between stable and beta channels, and the inability to "update" to a lower version is causing some strife. Is there a fork I can take a look at to see if this will help?

[alesser]

@hs-hub-world : Very much looking forward to the rollback feature as others are here. Do you have a branch we can look at while we wait, or are you expecting to make a PR soon anyhow ?

[PassivePicasso]

@paulcbetts Using an increasing version number strategy for multiple release channels doesn't really work in a good scenario. I have this setup where I am and it causes a lot of extra work when I need to migrate people between channels, and it is uni-directional.
This means a user cannot be given the ability to choose the release channel they want to be on as the version numbers wouldn't change.

@hs-hub-world Is there any developments on this front?

[AdhamAwadhi]

Any update on this?

[luetm]

I'm not sure I'm doing this right. For us it's very important that the user uses the same version on the client (which we update with squirrel) as the server (octopus deploy). Some people work at two of our customers at the same time, and then need to switch the version.

I have two repositories: _///update/stable_ and _///update/test_ . When a user connects to 'test', he upgrades to lets say 1.0.1. So far so good. But when he switches back to a prod environment again, it will stay on 1.0.1, even though the RELEASES on the _///update/stable_ says that the newest version is 1.0.0. When launching with 'prod'

• updateInfo.CurrentlyInstalledVersion.Version = 1.0.1 (which makes sense)
• updateInfo.FutureReleaseEntry.Version = 1.0.1 (which doesn't make sense imo)

I guess I have to parse the RELEASES manually and then delete the appropriate release in %localappdata%/Myapp? Is there a better way?

[MayaWolf]

Any news? Would also be important for us that people can switch freely between beta and release - including a potential downgrade to the most recent version on the selected channel.

[luetm]

I emailed with Paul, they are not interested in implementing it. :/

Usually if you're rolling something back in stable, you want to roll it back in all of the newer channels as well. Also hopefully rolling back is something you do very rarely, so that you don't encounter these situations so often!

They don't get that usecase, unfortunately, where people switch back and forth in versions.

[anaisbetts]

They don't get that usecase, unfortunately, where people switch back and forth in versions.

I do understand that use-case, but I don't believe that it's worth up-ending How Squirrel Works to do it. Squirrel intentionally makes uninstall and install really fast, so that reinstalling just Isn't A Big Deal. When people are downgrading, it's because the App Doesn't Work Right - you don't want that to happen often! Downgrades should be rare, and because this event is Rare, it is Reasonable to ask people to do something unusual.

[luetm]

When people are downgrading, it's because the App Doesn't Work Right

No, that's the point! A lot of people have parallel channels. Some users switch back and forth between them, without there being an issue. A user who works at two sites, that are not on the same update schedule for example. That user switches back and forth _very often_ and not because the software is faulty.

I don't believe that it's worth up-ending How Squirrel Works to do it

Doesn't squirrel save the latest few versions on the disk anyway? Couldn't the launcher just switch between those? (Just a suggestion)

[anaisbetts]

No, that's the point! A lot of people have parallel channels. Some users switch back and forth between them, without there being an issue. A user who works at two sites, that are not on the same update schedule for example. That user switches back and forth very often and not because the software is faulty.

I understand, but I also think that this is a Fundamentally Bad User Experience, and that you shouldn't ask users to do this, and I don't think that Squirrel should up-end itself to make this possible.

Understand that for Squirrel, I am very conservative about breaking changes, moreso than I would be about other projects - breaking an updater is catastrophic, because you can't update them to fix it. When Slack broke their Sparkle-based updater for the macOS app, it took them multiple years to fix it and get people back onto a supported version. The bar for change is High, and the bar for "Fundamentally change how Squirrel does update resolution" is extremely High.

[SartorialOffense]

If there is too much risk to breaking Squirrel because you need to redo too
much plumbing, I can totally understand why you won't change it. But I am
not sure I understand the bad user experience bit. This whole
Prod/Dev/Test channel thing is awesome for power users that handle final
testing. Power users can provide feedback on new features and simply flip
back to the prod anytime or stay on the less stable channels permanently.
Regular users never even notice this in their settings so their experience
doesn't suffer. For example, Chrome does this successfully.

On Wed, Aug 15, 2018 at 11:17 AM Paul Betts [e-mail]
wrote:

No, that's the point! A lot of people have parallel channels. Some users
switch back and forth between them, without there being an issue. A user
who works at two sites, that are not on the same update schedule for
example. That user switches back and forth very often and not because the
software is faulty.

I understand, but I also think that this is a Fundamentally Bad User
Experience, and that you shouldn't ask users to do this, and I don't think
that Squirrel should up-end itself to make this possible.

Understand that for Squirrel, I am very conservative about breaking
changes, moreso than I would be about other projects - breaking an updater
is catastrophic, because you can't update them to fix it. When Slack
broke their Sparkle-based updater for the macOS app, it took them multiple
years to fix it and get people back onto a supported version. The bar
for change is High, and the bar for "Fundamentally change how Squirrel does
update resolution" is extremely High.

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

[anaisbetts]

But I am not sure I understand the bad user experience bit.

I was referring to @leutm's case, where users have to switch between Squirrel release channels multiple times per-week, in order to have the right version that corresponds to a server-side version in their workplace.

Regular users never even notice this in their settings so their experience doesn't suffer. For example, Chrome does this successfully.

Chrome will definitely not let you downgrade on-the-fly, it will keep you on that version until Prod catches up (just like Squirrel will) and in fact, often does one-way migrations of user profile data that can't be downgraded without data loss.

[luetm]

@paulcbetts
'Bad User Experience': With us, it works exactly the same as @trumbjd explains. Some of our _customers_ (sites) help us test the new versions, but some of the individual _users_ work at multiple sites at the same time. Why do you call this a 'Bad User Experience'?

'Up-Ending': Would the approach of switching between the already installed versions work? Squirrel just needs to check what the newest version on that channel is and take this one.

Look, nobody wants the setup to break and I understand that it's annoying that everyone wants something done. And I also understand being conservative about changes. But if it would be technically possible to do, without 'Up-Ending', it would be a very useful and valuable feature that supports an important workflow - apparently not only for me.

[anaisbetts]

@luetm If you want to do this, you are totally free to do so in your own fork of Squirrel, what I'm saying is, that I will not take this change in the upstream version

[luetm]

@paulcbetts But what makes it a Bad User Experience? I genuinly like to know :/

[Kirides]

Why don't you "just" create separate installations for your "channels".
More like "Visual Studio Code" and "Visual Studio Code Insiders" which are technically just separate channels but designed as seperate installations, to make moving channels a lot more comfortable

[lukeskinner]

For anyone desperate for a solution you can hand roll this yourself if you want to handle this outside of Squirrel.

It isn't quite copy/paste code but here is the snippet we are using. We've had this in use for almost 2 years.

The only shortcoming which may be a deal breaker is if your app fails to install it will leave your program uninstalled (the installer does a uninstall, then reinstall). We've only had a couple users with anti virus problems causing the reinstall to fail.

Note: You do have to store a copy of all your previous installers on a URL/folder somewhere. If you don't have those this won't work.

```c#

if (updateInfo.FutureReleaseEntry.Version > updateInfo.CurrentlyInstalledVersion.Version)
{
//New version

    await updateManager.DownloadReleases(updateInfo.ReleasesToApply, SetProgress);

    await updateManager.ApplyReleases(updateInfo, SetProgress);
}
else if (updateInfo.FutureReleaseEntry.Version < updateInfo.CurrentlyInstalledVersion.Version)
{
        //Rollback

        string downloadUrl = "";
        string localFilePath = "";

        //TODO implement WebClient or HttpClient download from 'downloadUrl' to 'localFilePath'

        Process.Start(localFilePath);
        Environment.Exit(0)
}

```