Skip to content
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

Open
499105097 opened this issue Aug 19, 2024 · 6 comments
Open

How to GrayRelease #702

499105097 opened this issue Aug 19, 2024 · 6 comments

Comments

@499105097
Copy link

499105097 commented Aug 19, 2024

I want to use GrayRelease, is there any good plan?

@499105097 499105097 changed the title Grayscale publishing How to GrayRelease Aug 19, 2024
@ravibpatel
Copy link
Owner

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)

@rsteimen
Copy link

rsteimen commented Oct 19, 2024

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.
Before updating a client, this library would generate a random value between 0.0 and 1.0 and compare it to “item.updatechance” in the XML. If the generated random value is lower, the client updates. Otherwise, nothing happens.

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?

@ravibpatel
Copy link
Owner

@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.

@rsteimen
Copy link

@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.
After looking at the code around IPersistenceProvider I'm a bit skeptic if it's ideal to combine 'remind later' with my approach. I fear the necessary changes could make the 'remind later' code more complicated and therefore harder to maintain in the long run.

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.

@499105097
Copy link
Author

@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.

@ravibpatel
Copy link
Owner

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants