Workflows Versioning

Understanding the life-cycle of the Workflows ecosystem is an important topic, especially from a blocks developer perspective.

Rules

• Workflows is part of inference — the package itself has a release whenever any of its components changes and those changes are ready to be published.

• Workflows Execution Engine declares its version. The game plan is the following:

  • Core of workflows is capable of hosting multiple versions of the Execution Engine — for instance, the current stable version and a development version.
  • The stable version is maintained and new features are added until there is need for a new version.
  • Since a new version is fully operational, the previously stable version starts being deprecated — there is a grace period when the old version will be patched with bug fixes (but new features will not be added).
  • Core library only maintains a single Execution Engine version for each major — making a promise that features within a major will be non-breaking and a Workflow created under version 1.0.0 will be fully functional under version 1.4.3 of the Execution Engine.

• To ensure stability of the ecosystem over time:

  • Each Workflow Definition declares the Execution Engine version it is compatible with. Since the core library only maintains a single version for the Execution Engine, version: 1.1.0 in a Workflow Definition actually requests Execution Engine in version >=1.1.0,<2.0.0.
  • Each block, in its manifest, should provide reasonable Execution Engine compatibility — for instance, if a block relies on an Execution Engine feature introduced in 1.3.7, it should specify >=1.3.7,<2.0.0 as compatible versions.

• Workflows blocks may be optionally versioned (which we recommend and apply for Roboflow plugins):

  • We propose the following naming convention for blocks' type identifiers: {plugin_name}/{block_family_name}@v{X}.
  • We suggest to only modify a specific version of the block if a bug-fix is needed; all other changes to a block should yield a new version.
  • Each version of the block is to be submitted into a new module — even for the price of code duplication, as we think stability is more important than DRY in this particular case.
  • On a similar note, we suggest each block to be as independent as possible, as code which is shared across blocks may unintentionally modify other blocks, destroying the stability of your Workflows.