Misleading content in Explain_TargetVersionPrefixGoogleChrome in GoogleUpdate.adm |
|||||||
Issue descriptionChrome Version: any, e.g. 63.0.3239.132 OS: Windows What steps will reproduce the problem? (1)Install not latest minor version of Chrome in latest branch e.g. 63.0.3239.84 (2)Configure TargetVersionPrefixGoogleChrome as 63.0.3239.108 (to point to not latest minor in a branch). Can simulate it via: curl -H "Content-Type: application/json" -X POST "https://update.googleapis.com/service/update2" -d '<?xml version= "1.0" encoding="UTF-8"?><request protocol="3.0" version="1.3.33.7" shell_version="1.3.33.5" ismachine="1" sessionid ="{23864F1D-8C82-48BF-8DB3-F364CE8C17D6}" installsource="update3web-ondemand" requestid="{0A81035E-24DD-4411-A463-C 86DB1CA4BD3}" dedup="cr"> <hw physmemory="4" sse="1" sse2="1" sse3="1" ssse3="1" sse41="1" sse42="1" avx="1"/><os p latform="win" version="6.1.7601.0" sp="Service Pack 1" arch="x64"/> <app appid="{8A69D345-D564-463C-AFF1-A69D9E530F 96}" version="63.0.3239.84" nextversion="" _numaccounts="1" _numsignedin="0" ap="x64-stable" lang="" brand="GCEB" client="" installage="0" installdate="4025" cohort="1:gu/mhl:" cohortname="63_win_132"><updatecheck targetversionpr efix="63.0.3239.108"/><ping active="0" rd="4025" ping_freshness="{52BFF5ED-C792-4565-9232-2BF9748A8035}"/> </app></ request>' What is the expected result? Per documentation, users expect to receive upgrade to 63.0.3239.108: "Explain_TargetVersionPrefixGoogleChrome=Specifies which version Google Chrome should be updated to.\ ...... 4) Policy value is "55.24.34", the app will be updated to this specific version only." What happens instead? Receiving updatecheck status="noupdate" This is expected as we are aware that it's working for major versions only (e.g. "63.") So, request to update adm documentation accordingly.
,
Jan 10 2018
,
Jan 16 2018
We're not planning any further M63 releases. +abdulsyed@ (M64 release TPM)
,
Jan 16 2018
,
Jan 19 2018
blumberg@ Gentle Ping! This issue is marked as RB-Stable for M64, could you please let us know is there any latest update available on this issue? Thanks!
,
Jan 19 2018
RBS and milestones removed as this is a documentation change, no reason to block stable on it. Changes should be reflected in this: https://support.google.com/chrome/a/answer/3204698 article. Josh & Georges, can either of you confirm that we are only supporting 'major version' and not minor with this feature? Just need confirmation so Matt W can update the HC article with the proper limitations.
,
Jan 19 2018
That's correct, only the milestone number (major version) is supported.
,
Jan 19 2018
Matt W, Can you update the HC article in c#6 to explain that only current stable and n-1 are available and only the major version (not minor).
,
Jan 22 2018
I've added this text: "Note that you can only pin to a major release of Chrome (such as Chrome 63, 64, and not a minor version such as 63.0.3239.132)." to this article draft: https://support-content-draft.corp.google.com/chrome/a/answer/3204698 Can you review and let me know if this looks good to publish, or if additional changes are needed?
,
Jan 22 2018
-Let's give explicit examples -Should include the . after major version to avoid any possible future mismatching To prevent Windows machines from updating to versions of Chrome beyond the number you specify, use the TargetVersionPrefix policy. For example, you can pin the Chrome version "63." via the policy to prevent devices from updating past Chrome 63. Note that version pinning should only include the major release number of Chrome (such as Chrome 63. or 64. ). Attempting to pin to a minor release number will not work. However, you should try to avoid version pinning. If you forget to unpin your users’ machines, they can fall behind on critical security updates and miss out on new features in Chrome.
,
Jan 23 2018
Thanks for this update! I updated this text today, and it's live in this article: https://support.google.com/chrome/a/answer/3204698. Please email me if any additional updates are needed.
,
Apr 13 2018
,
Dec 7
Hello! This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time. - If you are currently working on this bug, please provide an update. - If you are currently affected by this bug, please update with your current symptoms and relevant logs. If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary. Thank you!
,
Dec 7
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by jayhlee@google.com
, Jan 10 2018