Refined Approach to Network Upgrade Planning:

[luckyparadise]

Refined Approach to Network Upgrade Planning: Insights and Actions

Following discussions during our recent Core Devs meeting HERE, a consensus has emerged on refining our approach to planning and communicating network upgrades. This discussion post outlines collective insights and actionable suggestions aimed at enhancing our upgrade planning processes.

Overview of Discussions

Initiated by Orjan Roren, the conversation illuminated various challenges impacting the NV22 upgrade timeline, including:

• Integration and Testing Complexities: Highlighting the complexity of ensuring network readiness through comprehensive testing across multiple client implementations and integrating significant protocol changes like the DDO protocol.
• Timely Code Freezes: A two-day delay in the actor code freeze underscored the tight interdependencies within our upgrade timelines.
• Ecosystem Tooling and Infrastructure Readiness: Substantial ecosystem tooling changes and critical infrastructure migrations, compounded by external factors such as the Chinese New Year, have posed additional challenges.

In response, we recognize the need to improve our planning and communication strategies for network upgrades, especially as pre-scheduled upgrades demand more precise and efficient planning to alleviate engineering pressure and allow thorough network testing.

Suggestions for Enhanced Planning

Communicating Upgrade Timelines

• Flexible Timeline Ranges: Our strategy will now present upgrade timelines as flexible ranges ("Mid March, Early June," etc.) rather than fixed dates. This approach, accommodating unforeseen challenges, will be refined with specific dates provided by implementers at least 4 weeks before the anticipated range.
• Incorporating Buffer Periods: Building buffer periods into our planning will allow us to absorb delays without compromising the timeline's integrity.
• Establishing Quarterly Upgrade Windows: We will continue to structure network upgrades on a quarterly basis as much as feasible.

Specific Next Steps

To ensure the successful implementation of our proposed enhancements to the network upgrade planning process, we have outlined the following specific actions:

1. Soliciting Feedback from Core Devs: This discussion post will be shared directly with Core Devs to gather their feedback and additional insights. Engagement from this group is crucial for refining our approach and ensuring it aligns with the needs and expectations of all stakeholders involved in the upgrade process.

2. Revision of the Upgrade Calendar:

   • Governance PM (Lucky) to Revise Upgrade Calendar: In line with the suggestions outlined above, I will revise the scheduled upgrade calendar for the remainder of the year. This revision will reflect the proposed flexible timeline ranges and incorporate buffer periods to accommodate unforeseen delays or challenges.
   • Communication of NV22 Timeline Changes: I will also communicate the recent changes to the NV22 upgrade timeline to the community.

Call for Feedback

I look forward to your comments especially from implementation teams and Core Devs, on these proposed changes.

[Fatman13]

Flexible Timeline Ranges: Our strategy will now present upgrade timelines as flexible ranges ("Mid March, Early June," etc.) rather than fixed dates. This approach, accommodating unforeseen challenges, will be refined with specific dates provided by implementers at least 4 weeks before the anticipated range.

How flexible will the range be? Say if upgrade is announced to target "Early June", what would be the worst case for upgrade date?

[LesnyRumcajs]

I believe the worst-case could be even up to 3 weeks or so, especially if the upgrade is scheduled before a major holiday period, e.g., Mainnet upgrade: Mid-December 2024. In my view, the range should be as flexible as it needs to be - if there's a requirement from the implementation teams to postpone the upgrade for any reason, e.g., complex migration + timing, it should be postponed. Otherwise, we may end up having major issues for the sake of a timely upgrade.