You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, by default, Lightning will save the adaptor version on each step as @latest. This is presented to users like this:
The @latest flag is resolved at runtime - so new work orders from the same workflow, by default, may use different adaptor versions.
This is terrifying. I didn't realise we did this! Stu and I clearly miscommunicatid over this a long time ago.
The problem is that we release breaking adaptor versions, with major version bumps, all the time. We have to. But this puts workflows with @latest at risk because one day, maybe in 5 years time, they'll break overnight without warning.
The Solution
Here is what we're going to do:
New steps, by default, should select the latest adaptor version - but not @latest
@latest should appear at the top of the picklist, but not selected by default.
We must ensure that when an step is selected in the diagram, the UI shows the actual version number, and not just the latest one as a default (I think this is fine but we need to double check).
We display a warning to users who select @latest to notify them that future breaking changes to the adaptor may cause their workflow to break.
Basically, by default, I want all steps to have version locked adaptors and not use a rolling @latest tag. But we are going to allow users to opt-in to @latest if they really want to (your funeral, pal).
This is much safer from a workflow stability point of view. But I will not that there's a bit of a security hit. When we release security patches, users will not automatically receive them.
Other steps
Should we migrate all @latest in the database right now to a concrete version number?
Who do we need to tell about this change? I think we need to make noise here
We should think about how we encourage users to manually migrate adaptors to include new security releases. Usually this is trivial, but when there are breaking changes we need to make real noise about them. I think this is a call for a future feature to email lightning users when a workflow they created/modified has a related adaptor release.
The text was updated successfully, but these errors were encountered:
Priority issue!!
The Problem
Right now, by default, Lightning will save the adaptor version on each step as
@latest
. This is presented to users like this:The
@latest
flag is resolved at runtime - so new work orders from the same workflow, by default, may use different adaptor versions.This is terrifying. I didn't realise we did this! Stu and I clearly miscommunicatid over this a long time ago.
The problem is that we release breaking adaptor versions, with major version bumps, all the time. We have to. But this puts workflows with @latest at risk because one day, maybe in 5 years time, they'll break overnight without warning.
The Solution
Here is what we're going to do:
@latest
@latest
should appear at the top of the picklist, but not selected by default.latest
one as a default (I think this is fine but we need to double check).@latest
to notify them that future breaking changes to the adaptor may cause their workflow to break.Basically, by default, I want all steps to have version locked adaptors and not use a rolling
@latest
tag. But we are going to allow users to opt-in to@latest
if they really want to (your funeral, pal).This is much safer from a workflow stability point of view. But I will not that there's a bit of a security hit. When we release security patches, users will not automatically receive them.
Other steps
@latest
in the database right now to a concrete version number?The text was updated successfully, but these errors were encountered: