docs: Update release process#423
Conversation
zanicar
force-pushed
the
zanicar/release-strategy
branch
from
57dde9b to
cb08aca
Compare
|
|
||
| Additional labels for release-candidates, pre-release versions and other build metadata are available as extensions to the Major.Minor.Patch format. | ||
|
|
||
| **Note:** Any dependency updates that are not state breaking, e.g. updating the Go version, fall under minor. |
There was a problem hiding this comment.
Would prefer to have it documented how often we would Minor and Patch bump when there are no consensus breaking changes.
Eg. we do a go version update with no state break, do we immediately tag that with minor bump so any new validators and nodes can use this latest instead?
Do we make a new release every time we merge to main something which isnt meta change(e.g ci or workflow or docs)? So basically, any binary change PR to main would be accompanied with a release?
There was a problem hiding this comment.
If yes, would similar logic apply for consensus breaking changes? Do we tag a major version as soon as a state breaking PR is merged? (Tangent: Would be nice to have some gh workflow which checks that when there is a major version bump, an upgrade handler for that version must exist)
If no, does that mean we should batch the non state breaking changes into single release? What would be the release schedule in such case?
There was a problem hiding this comment.
These are great questions! It would largely depend on the perceived impact of the update across the ecosystem.
Consider for example if we do a non-state breaking, but API breaking change; We probably don't want to immediately tag and release this to provide developers time to integrate and test. Thus, we might prefer to do such a release more akin to a major update with some formal coordination;
Conversely, if we update the Go version, which would result in a minor version bump, we could immediately tag such a release as its impact would be mostly superficial;
I do like the idea of having a workflow to check for an upgrade handler for that version 👍🏻
In general, I believe we should be more selective with major version releases and handle them on a case by case basis. IMHO blockchain release is more akin to traditional software pre-Internet era, as patches and fixes could not easily be rolled out. Thus greater care needs to be taken with each major release as the "move fast and break things" approach is disconcerting in an immutable state (blockchain) environment.
There was a problem hiding this comment.
Regarding the distinction between binary updates vs non-binary updates...
We could simply add any non-binary updates, e.g. docs, workflows, etc. under unreleased version until we have an actual binary update and tag along with the updated binary release; I believe this will provide for a more consistent upgrade path where every release is associated with a binary update.
|
|
||
| 1. Tx `GasWanted`; | ||
| 2. Tx `GasUsed` - which is Merkelized, thus any logic affecting this will result in state changes; | ||
| 3. Tx response `Data` - protobuf encoding changes result in state changes; |
There was a problem hiding this comment.
I think the msgs format in a transaction are also state breaking. So the Tx input as well as Tx response
Co-authored-by: Spoorthi <9302666+spoo-bar@users.noreply.github.com> Signed-off-by: Zanicar <38106253+zanicar@users.noreply.github.com>
Co-authored-by: Spoorthi <9302666+spoo-bar@users.noreply.github.com> Signed-off-by: Zanicar <38106253+zanicar@users.noreply.github.com>
zanicar
force-pushed
the
zanicar/release-strategy
branch
from
4b3d997 to
b5ac384
Compare
3 participants
No description provided.