I’m not sure how you’re getting your styles now. The AUI components should be updated mostly for “free”, but I understand everything might need a tweak for unique contexts and bespoke components will need to be styled to match. I can think of four possible options for you to achieve this.
If you’re using the LESS support in Web Resources Manager, then you have access to LESS variables. For our own code, we put all our variables in a “global.less” file that we
@import into every other file. This way our colors/spacings/etc are defined in one place. All these options depend on you having something like that (and now you’d have two version of that file).
One option is a build-time task that chooses which version of the file to use for different versions of the plugin. But I know that having two versions of the plugin has maintenance problems of its own.
Another option is to write a Web Resource Manager Transformer that checks the product version and transforms the content of each LESS file so that it @imports the right set of variables for that product version. The
<transformer key="lessTransformer" /> can be called afterward to act on output from your transformer. I believe you’d have to apply this transformer to every LESS file that needs multiple styles (because LESS @imports use file paths directly, there’s no way to transform the import that I can think of.
The third option is to have 2 web-resources for every file that needs alternate styles. You can use a Web Resource Condition so that only one of them actually gets on the page, depending on product version. These web resources would contain one file that imports a given version of your variables and then imports the content that will use each set of variables. I’m told this is a pattern used by our Portfolio team. So the file in each resource would look something like:
The last option I can think of is potentially riskier. Our own LESS variables are not stable API and can change at any time. But if you’re happy with that risk, you might be able to use it to your advantage. In LESS, the last definition of a variable wins. So if you know there is a variable in new versions that isn’t in older versions, you can “underwrite” with a fallback. The code would look something like:
// @ak-color-N20 was added in 5.10, so you can set a value for use in versions before that.
// @ak-color-N20 will get overwritten here in 5.10.
color: @ak-color-N20; /* custom or new value, depending on product version */
But note that this is not API and subject to change. The effect would be that if this variable goes away in 5.11, you’ll start showing old styles in 5.11 and have to find another workaround.
They all have pros and cons, but hopefully, one of those works for you!