2025 Network Upgrade Schedule

[luckyparadise]

[Updated 9 October 2024]

Core Devs and Implementers have agreed to maintain alignment with pre-scheduled upgrades, recognizing the benefits to the community and the teams involved in planning and deployment. Upgrades are costly and require significant coordination, making pre-scheduled upgrades valuable for predictability in planning.

Below are the proposed dates for the 2025 upgrade cycle. Your input is welcome

NV25 Upgrade (Q1 2025)

• Suggested Code Freeze Day: Monday, March 3, 2025
• Calibnet Upgrade: Wednesday, March 19, 2025
• Mainnet Upgrade: Wednesday, April 16, 2025

NV26 Upgrade (Q2 2025)

• Suggested Code Freeze Day: Monday, June 2, 2025
• Calibnet Upgrade: Wednesday, June 18, 2025
• Mainnet Upgrade: Tuesday, July 15, 2025
  • This avoids most of the European summer holidays while keeping the upgrade spaced out from Q1.

NV27 Upgrade (Q3/Q4 2025)

• Suggested Code Freeze Day: Tuesday, September 2, 2025
• Calibnet Upgrade: Wednesday, September 17, 2025
• Mainnet Upgrade: Tuesday, October 14, 2025

[rjan90]

Hey!

Thank you for preparing the network upgrade agenda for 2025. I appreciate the effort in planning ahead. I'll review the proposed dates more thoroughly and cross-check them with some holiday calendars around the world.

My initial feedback is as follows:

1. In 2023 we shipped 3 network upgrade, and we are on track to ship 3 network upgrades in 2024. I don't anticipate us doing more than 3 in the coming year either, as this already stretches the current capacity of our community and implementation teams.
2. I don't believe we should aim for a specific number of network upgrades as a goal in itself. Each upgrade comes with significant costs for the network as a whole, so we should focus on shipping upgrades that provide clear value and with too many uogrades planned it is harder to bring value to each of them.
3. That said, I do appreciate the idea of pre-determined date ranges for potential upgrades. This approach allows us to start coordination efforts early, which is beneficial.

[anorth]

Registering my disagreement with the sentiments above.

[luckyparadise]

Hey @rjan90!

I tried to put all the holidays into consideration but let me know if i missed anything.

1. While this is true, I think the idea of pre-scheduling this upgrade is to ease planning with implementation teams and resource allocation. Having the dates in the books does not mean we MUST ship something. In addition, the additional upgrade I included will be helpful in case timelines slip again and we need a buffer period.
2. I do not agree with this POV. I do think the opposite is true. When we have these pre-scheduled, we can allocate different FIPs and improvements to align with the various upgrades we have planned. If an upgrade is due and there are no significant improvements or FIPs, we can move to the next date or period on the other hand, if there are too many we can move the overflow to the next upgrade based on importance and prioritization.

[BigLep]

Hi @luckyparadise. I agree with @rjan90. Thanks for helping ensure intentional thought goes into the 2025 network upgrade schedule.

Here are thoughts from my end:

Core Devs and Implementers have agreed to maintain alignment with pre-scheduled upgrades, recognizing the benefits to the community and the teams involved in planning and deployment. Upgrades are costly and require significant coordination, making pre-scheduled upgrades valuable for predictability in planning.

I largely agree because:

1. I believe Moving to prescheduled network upgrades #145 covered well the rationale for having a more predictable upgrade schedule.
2. The nv23 upgrade tracking master doc, while incomplete, gives a good sense of the “cost” of doing a network upgrade in terms of the number of steps, time for those steps, and parties involved.

I caveated my agreement because there is also the need to have some flexibility to be reactive and accommodating of implementation teams.

I tried to put all the holidays into consideration but let me know if I missed anything.

Minor, but I think it would be helpful as part of this exercise to list out the various international holidays and major ecosystem events we’re accounting for.

Having the dates in the books does not mean we MUST ship something… If an upgrade is due and there are no significant improvements or FIPs, we can move to the next date

What I’m hearing you say is that we can just skip an upgrade if there is nothing meaningful for it. (There is no concern or pushback from me here on this point). The downsides of the approach of scheduling 4 upgrades but likely only executing 3 are:

1. It can “cast a cloud” across the whole projected 2025 schedule at the beginning of the year. It leaves the community guessing as to if/which network upgrade is going to be skipped.
2. It creates a larger-sized hole in the year unnecessarily (assuming we do indeed skip an upgrade). To cover some of the hole, it then likely means we’ll pull in the dates of one of the future upgrades. That means the community is seeing disruption on two of the "planned upgrades" (the one that is skipped, and the one that is adjusted to cover the hole).

I think it’s pretty likely we’ll only get three 3 upgrades out in 2025, and thus likely we’ll hit the downsides. My reasons for predicting only 3 network upgrades (instead of 4) are:

1. Empirically it’s what we’ve seen the implementer community do the last three years. I don’t believe this is due to a lack of effort or resolve by the implementers. As shared by @jennijuju here, the general late Feb, early July, late Oct flow is practical; it “avoids major holidays and regular vacation gaps for teams and leaves enough room for network monitoring/analysis post each upgrade.”
2. The implementer community doesn’t seem in favor of it. In the 2024-08-27 implementer call, there was a pretty clear lack of enthusiasm for the idea of doing 4 upgrades in the year. I think in order to change that sentiment, there would need to be a grounded-and-motivated-by-users set of reason or compelling strategic reason (e.g., “2025 is make-or-break for Filecoin, and to really hit the network goals we need more network upgrades this year because of X, Y, Z”). I don’t believe implementers heard such motivation in the call.

I think some potential next steps here are:

1. List the dates we need to account for when doing 2025 planning.
2. Propose dates assuming 3 network upgrades
3. If there is still resistance to 3 network upgrades for the year, maybe resolve with some sort of vote? (I assume implementation teams are the main voters here, and I know the Lotus side will vote for 3 upgrades.)

[LesnyRumcajs]

I agree with the @rjan90 and @BigLep. I believe that we should be pragmatic and schedule what we think we'll actually aim to do do and not start with a stretch goal. If there's an important change that can't wait, I don't think there would be any opposition to squeeze in another upgrade. Also, it's usually a good practice to under-promise and over-deliver. :)

On a more technical side:

Network upgrades incur a significant cost from the implementation teams. This includes coordination, exhaustive testing on several networks, creating boilerplate code, communications etc. Those engineering-hours could be better utilised elsewhere, e.g., implementing shiny features, especially if only a nice-to-have FIP is in the scope.

State migrations. It's not only implementation teams that need to prepare for the upgrade, but also the users. In regular node case, the memory usage is comparatively low with potential peaks during state migrations. Around those, users may need to either temporarily upgrade their hardware (that's what Forest did in the past for snapshot service nodes) or manually bootstrap from a snapshot (random idea - would be nice to have it done automagically).

[luckyparadise]

See below a revised schedule based on all the comments and feedback received.

NV25 Upgrade (Q1 2025)

• Suggested Code Freeze Day: Monday, March 3, 2025
• Calibnet Upgrade: Wednesday, March 19, 2025
• Mainnet Upgrade: Wednesday, April 16, 2025
  • This allows teams to fully resume and prepare post-holidays, avoiding any conflicts in early January or February.

NV26 Upgrade (Q2 2025)

• Suggested Code Freeze Day: Monday, June 2, 2025
• Calibnet Upgrade: Wednesday, June 18, 2025
• Mainnet Upgrade: Tuesday, July 15, 2025
  • This avoids most of the European summer holidays while keeping the upgrade spaced out from Q1.

NV27 Upgrade (Q3/Q4 2025)

• Suggested Code Freeze Day: Tuesday, September 2, 2025
• Calibnet Upgrade: Wednesday, September 17, 2025
• Mainnet Upgrade: Tuesday, October 14, 2025
  • This respects key public holidays in October (e.g., U.S. Thanksgiving) and avoids cramming too much into the end of the year.