![[source]](https://prod-files-secure.s3.us-west-2.amazonaws.com/1d32ac13-88b8-41a5-8687-93dfc9a37db7/c7d35398-e4df-463a-b6a6-24df7c525981/Execution_Stack_Versioning_goal.png)
👉 superseded by FLIP 296: Utilize Dynamic Protocol State for Version Beacon (coordinating upgrades of the Execution Stack) 👈
*Any convention will probably be easy to change without a spork!*
[[source](<https://drive.google.com/file/d/1pm-9ycKQL8bf1RROdATtLJ0M1Be6y8Eh/view?usp=sharing>)]
Versioning the Execution Stack used by ENs, VNs, ANs
Outlook: ANs can decide on whose blocks’ execution states they can run scripts for across Execution HCUs
See blog post [1] for further details
Software Version - The version identifier of a binary distribution of Flow Node software. By convention, we use semver-ish tag in Git and Docker releases.
Software has bugs. and is frequently incomplete (e.g. API returning ‘not yet implemented’). The software version is a meaningful reference to describe what the software does in the real world.
However, we also desire a compact identifier [which we will call the ‘Component Version’] of how a Flow node should behave.
Component Version: version identifier for a component of the flow protocol. It references one specific behaviour of a sub-system (e.g. Execution Stack or HotStuff) of Flow, as prescribed by the protocol.
In the nutshell, for every block there is one and only one correct way of how to process that block, and how to evolve the execution state. For distributed BFT systems, we need this notion of ‘correct behaviour’, which is inherently implementation agnostic. We want to explicitly express that up to a certain view $v$, we want the protocol to behave in one way and for higher views differently.