-
Notifications
You must be signed in to change notification settings - Fork 771
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to GrayRelease #702
Comments
It is not supported directly. When you update the XML, it will notify the user when update check is triggered, so it is not possible to gradually provide updates to only some users. You may be able to control the rollout by handling updates manually, as shown here. You can randomally choose to remind later user about the update using following code. AutoUpdater.PersistenceProvider.SetRemindLater(remindLaterDateTime) |
Started thinking about a potential integration of staged rollouts too. For an exact implementation like e.g. Google PlayStore, a central server would need to collect and serve install statistics. This would eliminate the ease of a simple XML. Therefore I'd suggest a simple XML property “item.updatechance” to define a 'chance to update' as a percentage between 0.0 and 1.0 whereas 0.1 means a chance of 10% for a client to update and 1.0 100% updates. A value of 1.0 would be the default value and cause the same behavior as today. A release rollout person would be free to update the value in the XML manually or develop external tools to automatically increase the value gradually within a time period best matching specific needs. What do you guys think of such a simplified implementation? |
@rsteimen It is a nice idea, but it will create more chance of update prompt for user who opens the app frequently if developer are checking for updates on app startup, which is usually the case. It is better to combine your idea with Remind Later mechanism. If the user fails the chance check, it will prompt after sometime. Currently, Remind Later is not version specific because it won't make sense to make it version specific, but for this to work we need to create version specific remind later. Developer can decide not to make next update as gray release and that can cause issue with current remind later implementation. |
@ravibpatel Correct, users opening the app frequently would sooner or later get asked to update. While easier to implement, it's a downside, fully agree. What would you think about implementing gray releases separately from 'remind later'? I'm thinking of storing the client side calculated “update chance” value with the gray release version in the registry like RegistryPersistenceProvider. In AutoUpdater.CheckUpdate we should be able to perform the 'update chance check' before the 'remind later' code section. |
@rsteimen My current temporary solution is to determine whether the Version is grayscale by the last bit of the version in the XML file, such as: 1.0.0.1 is represented the last 1 gray version, if 0 is the official version, and then in the event of an AutoUpdaterOnCheckForUpdateEvent through custom logic to determine whether need to update the version, this scheme is customized. |
@rsteimen Yes, It is better idea to use the separate fields for update chance and gray release version but randomizing the update chance may pose an issue where if you don't have much ppl regularly using the app. It may happen that no user get the good update chance for update, so I think it should increase the update chance gradually after certain time. For example, if last update chance was 0.1 we can calculate it again but this time it will be >0.1. It can do this on regular interval or exponentially (1 week, 2 weeks, 4 weeks etc…). It is also a good idea to provide a configuration field for this interval. This way also ensures that all users will get the update eventually, without needing to increase the update chance on server side. |
I want to use GrayRelease, is there any good plan?
The text was updated successfully, but these errors were encountered: