Open rjan90 opened 2 months ago
@rjan90 : thanks for creating the issue. I'm capturing some notes based on my understanding from conversations last week.
Repo | Versioning up through nv24 | Versioning post nv24 |
---|---|---|
Lotus | 1.28.0 Even releases signifiy mandatory release per https://github.com/filecoin-project/lotus/blob/master/LOTUS_RELEASE_FLOW.md |
1.INCREMENT_ON_NETWORK_UPGRADE_OR_API_BREAKING_CHANGE.x per https://github.com/filecoin-project/lotus/issues/12072 Example: for nv24, Lotus will presumably be 1.29.0 (assuming no breaking changes beforehand). |
filecoin-ffi | Tracks Lotus mandatory versions (e.g., 1.28.0) | 0.ACTORS_VERSION.x (just like go-state-types) Not doing ACTORS_VERSION.x.x because of Go's handling of major versions greater than 1. Not doing 1.ACTORS_VERSION.x because there have already been releases with that version. This does mean that newer filecoin-ffi (e.g., 0.15.0 for nv25) will be lexicographically less than previous versions (e.g., 1.28.0). |
go-state-types | 0.ACTORS_VERSION.x (e.g., 0.14.0) | Same - no change. |
builtin-actors | ACTORS_VERSION.0.0 (e.g., 14.0.0) | Same - no change. |
I have wondered though if this change in network versioning is actually a good time to maybe break up the filecoin-ffi module into multiple? (I heard a couple of asks for it recently, but I can't remember the details - will capture it in an issue recently). I think it boiled down to the fact that some consumers only care about proofs while others only care about ref-fvm. We could allow them to update independently . (I don't know how much of a benefit that is vs. the cost of mainitaining more repos handling C and CGO bindings.)
Relevant #fil-curio-dev thread: https://filecoinproject.slack.com/archives/C06GD1SS56Y/p1719449072359519
For context, we have 4 versions:
We update the FFI when we cut a new network upgrade because each FVM release checks if it supports the requested network version. If we changed anything here, we'd version by network version, not actor version, IMO.
The current tag/versioning of Filecoin-FFI is inconsistent with other repositories (Go-State-Types/Builtin-Actors) and currently maps to the Lotus version
The FFI was built to be a part of lotus, that's why it aligns with the lotus version.
The go-state-types track the actors version because they provide actor-version-specific types.
Aligning the versioning will help maintain consistency across the project, reduce confusion, and improve the overall release process
Can you expand on this?
This alignment will also help in tracking dependencies and ensuring compatibility between different components of the Filecoin project, especially around network upgrades.
I'm not sure how tracking lotus releases versus tracking actor releases makes a difference here.
I think all this boils down to the fact that the FVM refuses to run if the network version is beyond the supported range. How about we just remove that check?
Done Criteria:
The versioning of Filecoin-FFI should be updated to align with the versioning scheme used by the builtin-actors, and the Development Guideline gets cleaned up and adjusted accordingly.
Why Important:
The current tag/versioning of Filecoin-FFI is inconsistent with other repositories (Go-State-Types/Builtin-Actors) and currently maps to the Lotus version. Aligning the versioning will help maintain consistency across the project, reduce confusion, and improve the overall release process. This alignment will also help in tracking dependencies and ensuring compatibility between different components of the Filecoin project, especially around network upgrades.
User/Customer:
Maintainers and developers who depend on Filecoin-FFI.
Notes: