3 Key Changes to the Lotus Release Process #12020
Replies: 3 comments 4 replies
-
|
Thanks for writing this up. |
Beta Was this translation helpful? Give feedback.
-
|
The revised versioning:
Separate Lotus Client and Lotus-Miner releases:
Faster releases
I will add a rollout-section to the OP, so that its a bit more clear when each of the steps will happen. |
Beta Was this translation helpful? Give feedback.
-
does this have to be blocked by Curio? Would look into if we can ship a lotus client release soon after v1.27.3 before nv23 release |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we can start working on that independent of Curio, I think. I don't believe there's anything stopping that except that it'll depend on how much other nv23 work "we" are tied up because shipping those features is probably highest priority, right? Ticket for it here for tracking: #12010 |
Beta Was this translation helpful? Give feedback.
-
Given that monthly will be a minimum... Could you provide more information about the average expectation? and how often exchanges and other key stakeholder will need to upgrade? In particular, what will be the upgrade schedule for calibration -> mainnet? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jleni! It seems like there are couple questions in here. So I will just try to clarify those: 1. Does more frequent Lotus releases mean that there will be a change when it comes to network upgrade schedules?
2. How often exchanges and key stakeholders will need to upgrade?
|
Beta Was this translation helpful? Give feedback.
-
|
@rjan90 and I connected verbally on this a bit today. I'm including my notes from the conversation. @rjan90 is going to create a tracking issue for the "Revised Versioning" work so it can have a checklist of the various steps that will need to be taken (e.g., update Lotus Release Flow markdown document), and so it can start showing up on boards/backlogs as a post nv23 item. The issue will also capture more of the motivation for the change to no longer need odd and even minor versions to signal mandatory vs. feature releases. My understanding is that since LOTUS_RELEASE_FLOW.md was first written ~3 years ago, Lotus' stability and release quality have both increased, which minimize the need for having a "mandatory even" minor version that can be easily patched. Instead, by default, a hotfix can be applied to the latest production release, even if it includes additional released-in-production features since the last network upgrade. |
Beta Was this translation helpful? Give feedback.
-
Hey everyone! We want to share some updates with regards to the Lotus release process going forward.
3 Key Changes to the Lotus Release Process
1. Revised Versioning:
We are revising the versioning strategy of Lotus to adopt a more user-friendly approach for our users, moving away from the mandatory (even) and feature release (odd) versioning scheme that has been the norm for the past couple of years.
After the
Lotus v1.28.0release is out which brings the changes for the next network upgrade (nv23), we will move away from the even and odd versioning.The format will still be
MAJOR.MINOR.PATCH, but with some nuanced changes compared to previous ways of doing it:MAJORif there are major changes to Lotus (e.g if we re-architect).MINORwhenever there is a network upgrade, API breaking change or non backwards-compatible feature enhancements.PATCHwhenever there are backwards-compatible bug fixes or feature enhancements.The Lotus Release Flow markdown document will be updated to reflect these changes once
Lotus v1.28.0lands. Its advised to subscribe to status.filecoin.io to get updates about dates for network upgrades. Whether a Lotus release is optional or mandatory for network upgrades will be clearly highlighted in the release changelog.2. Separate Lotus Client and Lotus-Miner releases:
Historically, the development and release cycle of the Lotus Client and Lotus-Miner have been closely intertwined, while they serve different audiences. As mentioned in this recent Filecoin blog post, FilOz is carrying on the maintenance and the development of Lotus Client, ref-fvm and builtin-actors with a focus on network, protocol and node operator needs. While the Curio Storage team is taking on lotus-miner & Boost maintenance with a focus on developing a set of software that Storage Providers can use, as well as building Curio (often referred to as Lotus-Miner-V2).
FilOz would like to support different users’ needs better by separating Lotus client releases (for node operators like API-providers, exchanges, SPs, apps, indexers, toolings) & SP software releases (for SPs) so users can better evaluate what, when and and whether they need to update their system.
The first step in this direction is that the Curio software (miner V2) will have a separate repo as its home (follow the #fil-curio-announcements channel in Slack for updates). Lotus-Miner (V1) will remain in the Lotus repo. FilOz will be conducting integration testing outside of the production lotus-miner code. This means having enough functionality to test new protocol features, etc. The Curio team will decide what new features and bug fixes to support in lotus-miner based on user needs.
3. Faster releases
Last year we took a step back, and introduced a slower release cadence (bi-monthly) to improve internal processes to make the quality of code, reviews and testing processes better. We feel we are now at a point where we would like to shift gears back again, and ship Lotus Client releases more often, as we have observed that a lot of our users, especially critical tooling builders, are waiting for features & enhancements to be shipped in a stable Lotus Client release. At minimum, we will ship a release every month.
We will continue to improve code quality, reviews, paying down tech debt and looking at deploying nightly deployments on master, etc. But we feel confident that we have a good basis to have more Lotus Client releases again.
Rollout of these changes:
Beta Was this translation helpful? Give feedback.
All reactions