I'd like to have the latest release and the dev branch be the same for longer. That is, not immediately branching off at the moment of release, but rather only on a breaking change.
To facilitate this, I think we can add a rudimentary but effective change detection gh workflow.
This is slightly different to other miden repos since the node is essentially a binary executable and not a library.
imo we have the following api surface:
- gRPC API external (RPC)
- node CLI
- protocol version
- breaking semantics
- Docker compose API for local node
Optionally, we could also include internal grpc API in case operators want to mix and match internal component versions. I will argue this is not necessary at this point.
Workflow outline
- Workflow runs on every PR to next/dev
- Detects possible breaking change
- Adds a warning comment on the PR describing breaks found
- Fails PR unless PR includes opt-out label (same as current changelog workflow)
Change detection
We can use the following
buf cli has this built in
- Git diff on relevant files, or a unit snapshot test which checks the help output of the cli for changes
- Git diff of lockfile and toml
- This will have to be manual
- Git diff
I'd like to have the latest release and the dev branch be the same for longer. That is, not immediately branching off at the moment of release, but rather only on a breaking change.
To facilitate this, I think we can add a rudimentary but effective change detection gh workflow.
This is slightly different to other miden repos since the node is essentially a binary executable and not a library.
imo we have the following api surface:
Optionally, we could also include internal grpc API in case operators want to mix and match internal component versions. I will argue this is not necessary at this point.
Workflow outline
Change detection
We can use the following
bufcli has this built in