Providing users the ability to use different upgrade paths

[ben.ganley]

Hi there,

Is there a way that I can have my users customize which version of the software they upgrade to while using the auto update feature?

For example, I want to have N, N-1 and N-2 update releases. More conservative customers may wish to set their auto updates to N-2 in our software.

Currently our software will invoke the updater based on configured auto update schedules set by the user; however it doesn't seem possible to pass in the args to the updater, which file to pull the available updates from.

Is there a way to achieve this currently, or would this need to be a feature request?

Many thanks

[Catalin]

Hello Ben,

You can have multiple updates presented to your customers and they can choose between those.

For example, if they have v1 and you released v3, they will be able to choose between v2 and v3 if that's how you configure it.

Currently our software will invoke the updater based on configured auto update schedules set by the user; however it doesn't seem possible to pass in the args to the updater, which file to pull the available updates from.

You can pass arguments to the updater, but it's from a predefined list.

Would that help?

Best regards,
Catalin

[ben.ganley]

Hi Catalin,

This doesn't work for us as these upgrades happen unattended.

We have a process that will invoke the auto updater using those command line params based on schedules defined in our application.

We want to be able to manage upgrade rings so that if there was to be an issue with an upgrade, all of our users don't get upgraded to it at once.

There would be a security issue if you could pass any update URL to the updater as you could then potentially inject a malicious application, however the ability to pass some variables that could then be appended as query params to the update URL would allow us to dynamically generate the update file and would resolve the issue for us.

We need to be able to achieve both a gradual rollout of updates as well as giving users the ability to not be on the bleeding edge of releases.

Many thanks

[Catalin]

Hello Ben,

Apologies for the quite delayed reply on this (I've had some sick days last week).

We need to be able to achieve both a gradual rollout of updates as well as giving users the ability to not be on the bleeding edge of releases.

Here are some articles that described gradual updates:

1. How to implement a comprehensive, scalable solution for granular updates across many servers?

2. How to handle incremental updates such as, canary and production updates?

Hope this helps!

Best regards,
Catalin