-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
This is a tracking issue for revising the Lotus Versioning
Problem to solve
We need to revise the versioning strategy of Lotus to adopt a more user-friendly approach, moving away from the mandatory (even) and feature release (odd) versioning scheme that has been the norm for the last years.
Why Important
Since LOTUS_RELEASE_FLOW.md was first written ~3 years ago, Lotus' stability and release quality have both increased. This proposal minimizes the need for having a "mandatory even" version that can be easily patched. Instead, by default, a hotfix can be applied to the latest production release, even if it includes additional backwards compatible features since the last network upgrade.
Historical Context
Historically, Lotus used an even and odd versioning scheme where even minor
versions indicated mandatory releases (network upgrades) and odd minor
versions indicated feature releases.
Reasons for Change
- Building a Great Blockchain Client: The goal is to make the Lotus Client a great blockchain client that people can build upon, enhancing its usability and appeal to developers and users alike.
- Decoupling Versioning: We are decoupling the versioning for Lotus Miner and Lotus Client to allow for more independent development and release cycles.
- Increased Stability: Over the past few years, Lotus' stability and release quality have improved significantly, reducing the need for a strict even/odd versioning scheme.
- Simplified Versioning: A more straightforward versioning strategy (
MAJOR
.MINOR
.PATCH
) will be easier for users to understand and follow. - Clear Communication: The new strategy will clearly highlight whether a release is optional or mandatory for network upgrades in the release changelog, reducing confusion.
User/Customer
Lotus Client users
Notes
After the Lotus v1.28.0 release, which brings the changes for the next network upgrade (nv23), we will move away from the even and odd versioning.
The format will be MAJOR
.MINOR
.PATCH
:
- Increment
MAJOR
if there are major changes to Lotus (e.g., if we re-architect). - Increment
MINOR
whenever there is a network upgrade, API breaking change, or non-backwards-compatible feature enhancements. - Increment
PATCH
whenever there are backwards-compatible bug fixes or feature enhancements.
Concerning branching:
- Releases will branch from master, regarldess if the release is for a network upgrade or not.
- Commits will almost always land in master.
- Commits may be cherry-picked into a release branch. This could occur when rushing out a release or during the RC phase of a release.
- There is no more "releases" branch.
A key callout is that a Lotus release that has the functionality for a network upgrade may likely have commits that haven't been deployed to production yet (besides new FIP functionality).
- Before: "mandatory" releases had "last production release + minimum commits necessary for network upgrade"
- Now: release for a network upgrade will have "last production release + minimum commits necessary for network upgrade + any other commits that have made it into master since the last production release".
This means a release accompanying a network upgrade may have commits that aren't essential and haven't been deployed to production. This is a simplifier and we think the risk is acceptable because we'll be doing releases more frequently (thus the amount of commits that haven't made it to a production release will be smaller) and our testing quality has improved since years past. (There is more discussion on this here.)
We expect:
- to be doing releases every ~4 weeks, except during network upgrade times given they have longer RC periods.
- reduce the RC period for releases that don't accompany a network upgrade to ~1 week.
### Tasks
- [x] Communicate new versioning strategy in a discussion post: https://github.com/filecoin-project/lotus/discussions/12020
- [x] Update[LOTUS_RELEASE_FLOW.md](https://github.com/filecoin-project/lotus/blob/master/LOTUS_RELEASE_FLOW.md) to reflect the new versioning strategy.
- [ ] Update release process to have a step for updating the Lotus version for all docs: https://github.com/filecoin-project/lotus-docs/pull/746
- [ ] Visual/text covering branch strategy and timelines
- [ ] https://github.com/filecoin-project/lotus/issues/12374
Metadata
Metadata
Assignees
Labels
Type
Projects
Status