Follow up to #6404
Currently we have the keys "default" and "legacy" and newly added for 1.34.0 "4.x". That's for setting the active version on admin/config/development/jquery
Those keys are used as value for jquery_version in system.core.json.
See the source code
It has been discovered that the choice for key names - "default" and "legacy" - isn't very future proof.
Instead, the actual version would be clearer and would make it easier to update the default version, only by adapting default JSON and form item descriptions.
However, that means that we have to change the setting for existing sites in an update hook. And this possibly affects implementations of hook_library_info_alter() in contrib and custom code. And any checks for the active version via config_get(). And custom install profiles. At this point it isn't clear, how dangerous such a change might be in terms of backwards compatiblity.
The desired key names:
- 1.x
- 3.x
- 4.x (we already have that)
Follow up to #6404
Currently we have the keys "default" and "legacy" and newly added for 1.34.0 "4.x". That's for setting the active version on admin/config/development/jquery
Those keys are used as value for
jquery_versionin system.core.json.See the source code
It has been discovered that the choice for key names - "default" and "legacy" - isn't very future proof.
Instead, the actual version would be clearer and would make it easier to update the default version, only by adapting default JSON and form item descriptions.
However, that means that we have to change the setting for existing sites in an update hook. And this possibly affects implementations of hook_library_info_alter() in contrib and custom code. And any checks for the active version via config_get(). And custom install profiles. At this point it isn't clear, how dangerous such a change might be in terms of backwards compatiblity.
The desired key names: