Align Filecoin-FFI Versioning with Builtin-Actors Versioning

rjan90 commented 2 months ago

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:

Aligning the versioning will require updating the release process and possibly the tooling used for versioning.
This change should be communicated clearly to all stakeholders to ensure a smooth transition.

BigLep commented 1 month 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.)

BigLep commented 1 month ago

Relevant #fil-curio-dev thread: https://filecoinproject.slack.com/archives/C06GD1SS56Y/p1719449072359519

Stebalien commented 1 month ago

For context, we have 4 versions:

FVM.
Lotus.
Actor.
Network.

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.

If you don't have the latest patch release of the FFI, your node may not go over the upgrade anyways.
The FFI already tracks lotus releases. Is this an ask from venus?

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?

filecoin-project / filecoin-ffi