Right now when a user is building a workflow and adds a new step, after they select an Adaptor the Version defaults to “latest”, which means this workflow will ALWAYS use the latest version of the adaptor. This creates problems if there is a major adaptor version release and suddenly users’ workflows get auto-upgraded to the “latest” version. We should default the Version to the most specific version… but then the step should be version-locked to avoid this scenario of a mistaken auto-upgrade to an incompatible version.
Ooh I just caught this today - I totally agree, and I’ve asked for an urgent fix
Just noting for the record that this cuts both ways. If the default is for everyone to not auto-upgrade, we’ll continue to have to support lots of very old adaptor version.
If it is to auto-upgrade, we’ll run the risk of some steps getting upgraded even though their authors didn’t want them upgraded.
Neither is ideal. Ideal is that we introduce a package.json/semver style field for adaptor version. How hard would that be @jclark , @stu , @roina ? I feel like we talked about this at some point but we haven’t really explored the costs.
My adaptor version could be any of these:
"language-dhis2": "1.0.0 - 2.9999.9999",
"language-dhis2": ">=1.0.2 <2.1.2",
"language-dhis2": ">1.0.2 <=2.3.4",
"language-dhis2": "2.0.1",
"language-dhis2": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
"language-dhis2": "~1.2",
"language-dhis2": "~1.2.3",
"language-dhis2": "2.x",
"language-dhis2": "3.3.x",
By default, I’d recommend that we set it to the most current version and allow all but major version bumps. At the time of writing, for dhis2, that would be 6.x.
This would mean that users get fixes (patch) and new helper functions (minor), but not breaking changes (major).
Thoughts?
I think auto-upgrade is potentially very dangerous. It means workflows WILL break one day. I mean, the salesforce 5.0 we’ve just put out will destroy every salesforce workflow if they start drifting onto it.
If we don’t auto-upgrade, it’s likely to be annoying at worst. But in practice we have to do very little active maintenance on old adaptor versions. I don’t think there are even many security concerns where we’d want to back and patch on old version.
I do agree that auto updating to the latest minor is the correct behaviour. Maybe we shouldn’t even let users pick a minor or patch release - they just pick 1.x or 2.x in the selector. For newer adaptors that should be perfectly safe. I suspect for older adaptors we’ll get away with it.
And we can always provide an advanced “enter a version number” UI, like we do in platform, for very rare cases where a patch-specific version is needed.
This model still means we have a long list of adaptor versions we need to maintain - especially because we tend to put out major updates with only small changes. So we also need some kind of secondary nudge to encourage users to migrate to the next major from time to time - whether this is a service we provide or some AI or just an email we send.
We could also consider some kind of automated process to deprecate or even remove old adaptor releases from npm which don’t have any weekly downloads. We must have loads of dead releases out there.