When you say explicitly I would assume that under Version Control you see just the version alone like in this picture.
If that's the case please open TAC case so we can investigate.
However if you see anything like this picture where the version has prefix Latest
That settings means that you want to be on the latest release the moment its released in the production automatically and this is very much expected. Me personally I would not recommend this setting for anything major like Secure Client aka Anyconnect or Secure Endpoint. Actually the only one that I will leave like that is Cloud Management the rest I would ensure is on version only without prefix Latest
Again Latest 8.5.0 is different than 8.5.0 the word Latest is a variable... in other words if latest today is 8.5.0 but over night we add 8.6.0 the policy with Latest 8.5.0 upgrade simply because Latest is no longer 8.5.0 but 8.6.0 and you will upgrade because that's what Latest means and this is expected ... if you don't want this to happened don't select Latest and select static version (NUMBER ONLY) if you you do not want to auto-update. There will be ALWAYS two latest version available in the drop down menu.
Latest (8.6.0.305781) -- > will auto change to the next latest once released
8.6.0.305781 ---------- > will stay on 8.6.0 regardless which version is latest
This setting is not the same
as this
The first setting means if we release 8.7.0 it will auto-update to 8.7.0 the second picture will stay on 8.6.0 until you make the change and save the deployment manually. Again two completely different settings even if both have same connector currently listed.
If you had selected under Version Control 8.5.0 and not Latest 8.5.0 and it did update open TAC case and submit logs we will be able to determine what was selected and if there was any issue. I just check my ORG where I was on 8.5.0 and it didn't update .
Thanks for the clarification. I now understand the difference between Latest (variable) and the static version number.
What caused the confusion for me was mainly the UI layout. The static version numbers are listed at the bottom of the list, while the Latest option appears at the top with the same version number. When someone sees Latest 8.5.0, it is very easy to assume that it simply means the current latest 8.5.0 build, not that it is actually a dynamic variable that will automatically move to the next release.
In other words, the interface makes it look like both options represent the same thing, even though their behavior is completely different.
I later noticed that the static versions are available further down in the list, but the placement makes this easy to miss. From a usability perspective it might be clearer if:
• Static versions (number only) were displayed at the top
• The Latest option was visually separated or placed in a different section
• Or a toggle such as “Always use latest version” was used instead of mixing it with fixed versions
I also created a small example UI design below to illustrate how this could be presented in a clearer way.
I believe this kind of layout would reduce confusion, because the current interface can easily lead administrators to unintentionally select a dynamic version instead of a fixed one.
Thanks again for explaining the behavior.
I designed an example interface concept. In my opinion, Cisco should definitely implement something like this, because I believe there are at least thousands of people around the world experiencing the same confusion. The current behavior is quite misleading, and I think it’s very important that the UI design is clearer and more intuitive.
If I want automatic updates, I should simply be able to click a button like “Always Use Latest Version”, and then the system would always update to the newest release automatically.
Another thing that feels strange is that version control exists in two different places: one in the package configuration and another in the Secure Endpoint policy. Why are there two separate controls for the same thing? In my opinion, version management should be handled from a single place.
For example, if I set the policy to 8.5, but the package version is 8.6, the system should not allow that configuration. Policies should either always be managed from Secure Endpoint or from one single centralized location, to avoid conflicting settings.
