Client V0.47.3 Release Discussion: Requirements And Comprehensive Steps

Hey everyone! Let's dive into the comprehensive process and crucial requirements for the client v0.47.3 release. This guide outlines all the necessary steps, from pre-release preparations to final publishing, ensuring a smooth and efficient update. Let's get started!

Requirements

Before we jump into the release process, it's essential to highlight some key requirements. Making sure we've ticked all these boxes ensures that our release is stable and well-prepared.

• Manual Editing: This release requires manual editing, especially to incorporate any pending Pull Requests (PRs). This step ensures that the latest changes and fixes are included in the release.
• Release Readiness: The release must be completely ready before proceeding. This means all critical features should be tested, and any known issues should be resolved. Ensuring release readiness guarantees a higher quality and more reliable client.

Pre-Release Preparations

Alright, folks, let's get into the nitty-gritty of preparing for the release. The pre-release phase is super important because it sets the stage for a smooth and successful launch. We're basically laying the groundwork here, so let's make sure we do it right!

Creating the perm-v0.47.3 Branch

First up, we need to create a branch called perm-v0.47.3. This branch will be our dedicated space for all the release-related activities. We'll branch off from the previous client git tag. Think of it like setting up a separate workshop just for this project – it keeps things organized and prevents any accidental mix-ups with other ongoing developments. The perm-v0.47.3 branch is crucial for isolating the release work, ensuring that any changes or updates made for this version do not interfere with the main development line.

Bumping the Client Version

Next on our to-do list is bumping the client version to v0.47.3 within our newly created branch. This step is like putting a shiny new label on our product – it clearly marks the version we're working on. Incrementing the client version in the perm-v0.47.3 branch not only helps in version tracking but also signals to the system and users that this is a distinct release with its own set of features and updates. It's a small change, but it makes a big difference in maintaining clarity and organization throughout the release process. Making sure the version is correctly updated prevents confusion and ensures that everyone is on the same page regarding the release version.

Release Steps

Now, let's move on to the actual release steps. This is where the magic happens, and we get to see all our hard work come together. Grab your coffee, and let’s dive in!

Tagging and Pushing to GitHub

The initial step in the release process involves tagging the commit with v0.47.3 and pushing this tag to GitHub. Tagging is like putting a stamp of approval on the release, marking it as the official version. The tagging process serves as a snapshot of the codebase at the time of release, which is crucial for future reference and debugging. Pushing the tag to GitHub makes it accessible to everyone involved in the project, ensuring transparency and collaboration. This step is pivotal because it creates a permanent marker in the repository's history, making it easy to revert to this specific version if needed.

Initiating the Publish Binary Draft GitHub Action

Next, we kick off the GitHub action “Publish Binary Draft.” This action automates the process of creating a draft release with the necessary binaries. We specify the range of versions we're moving from (v0.47.2) to (v0.47.3). Think of it as the assembly line starting up, building the release package. This automated process significantly reduces the manual effort required for preparing a release, ensuring consistency and accuracy. By using the GitHub action, we can streamline the creation of release binaries, making the entire process more efficient and less prone to human error.

To run this action, you'll use the following command:

gh workflow run "Publish Binary Draft" -r 'master' -f from=runtime-v0.47.2 -f to=runtime-v0.47.3

Reviewing and Cleaning the Draft Release

Once the draft is generated, it's time to put on our editor hats and review the release notes. We'll clean up the messages, making sure they're clear, concise, and informative. It's like proofreading your essay before submitting it – we want to make a good impression. Reviewing the generated draft ensures that the release notes accurately reflect the changes and improvements included in this version. This step is not just about aesthetics; it's about providing valuable information to the users, helping them understand what's new and how it affects them. Keeping the release as a draft at this stage allows for further modifications and refinements before the final publication.

Updating Moonbeam-Networks Stagenet Configuration

Now, let's update the moonbeam-networks stagenet (moonsama/moonlama) config.json file. This involves adding the binaries for v0.47.3. This step is crucial for testing the new client in a staging environment before the full release. Updating the stagenet configuration allows us to validate that the new client works seamlessly with the existing infrastructure. We'll add the following configuration:

"binaries": [
    {
      "docker": "moonbeamfoundation/moonbeam:v0.47.3-rc",
      "path": "/moonbeam/moonbeam",
      "name": "moonbeam"
    },
    {
      "docker": "moonbeamfoundation/moonbeam:v0.47.3-rc",
      "path": "/moonbeam/moonbeam-skylake",
      "name": "moonbeam-skylake"
    }
  ]

We also need to increase the config version by 1. It’s like updating the software version number in our system so that everything recognizes the new release. Increasing the configuration version ensures that the stagenet environment picks up the new binaries and configurations. This is vital for maintaining consistency and avoiding conflicts between different versions. Ensuring the configuration version is correctly incremented is a small but essential step in the release process.

Testing the New Client on Stagenet

With the configuration updated, we need to test the new client on the stagenet (moonsama/moonlama). This is our dress rehearsal, making sure everything works as expected in a controlled environment. Testing on stagenet helps identify any potential issues or bugs before the client is released to the main network. It’s like a trial run, giving us the confidence that the release will be stable and reliable. Thorough testing on stagenet is a crucial step in ensuring the quality of the release.

Checking glibc Version

Next, we need to check the glibc version using the following command:

objdump -T <binary> | grep GLIBC | sed 's/.*GLIBC_([.0-9] *).*/\1/g' | sort -Vu

This step ensures compatibility with the system's core libraries. It’s like making sure the new part fits the engine before installing it. Checking the glibc version helps us avoid runtime errors and compatibility issues, ensuring the client runs smoothly on different systems. This is an essential step in maintaining the stability and reliability of the release.

Publishing the Client Release Draft

Once we're satisfied that everything is working correctly, it’s time to publish the client release draft. This makes the release visible and available to the broader community. Publishing the draft release signals that we are confident in the quality and stability of the new version. It’s like opening the doors to the public after a successful preview. At this stage, the release is still considered a draft, allowing for final checks and feedback before the full publication.

Publishing the New Docker Image

After thorough testing and validation on stagenet, it’s time to publish the new Docker image. We use the GitHub action “Publish Docker” with v0.47.3. This step packages the client into a containerized format, making it easy to deploy and run in various environments. Publishing the Docker image is a critical step in ensuring that the client is accessible and deployable across different platforms. This is akin to packaging our product in a universal container, making it easy for anyone to use, regardless of their setup. It’s super important to note that this should ONLY be done after the client has been fully tested on stagenet.

Publishing the New Tracing Image

Finally, we publish the new tracing image. This involves starting the GitHub action “Publish Docker” with v0.47.3 and master on the moonbeam-runtime-overrides repository. The tracing image includes additional tools and configurations for monitoring and debugging the client. Publishing the tracing image provides essential support for diagnosing issues and optimizing performance. This step is like providing a toolkit alongside our product, enabling users to maintain and troubleshoot their setup effectively. Again, this step should only be performed after the client has been fully tested on stagenet to guarantee its reliability.

Conclusion

Alright, team! We've walked through all the steps for releasing client v0.47.3, from pre-release preparations to final publishing. By following these guidelines, we can ensure a smooth and successful release. Keep up the great work, and let's make this release our best one yet! Remember, each step is vital for the stability and reliability of the new client version. By paying attention to these details, we ensure a seamless experience for our users. Let's do this!