Stellar Anchor Platform Release 4.1.3: Discussion & Updates

Hey guys! Let's dive into the details of the Stellar Anchor Platform Release 4.1.3. This article covers everything you need to know about this release, from preparation to publication and post-publication steps. We'll break it down in a way that's super easy to understand, so you can stay up-to-date with all the latest changes and improvements.

Publish a FEATURE Release

This section outlines the steps to publish a feature release for the Stellar Anchor Platform. Follow these guidelines to ensure a smooth and successful release process. Let's get started!

Release Preparation

Before we even think about hitting that publish button, there's some prep work to do. Think of this as your pre-flight checklist – gotta make sure everything's in order before takeoff! Release preparation is critical. It ensures that the release process goes smoothly and that all necessary steps are completed before the actual publication.

• [ ] Decide on a version number based on the current version number and the common rules defined in Semantic Versioning. E.g. 4.x.x.

  • Figuring out the version number is the first step. We're using Semantic Versioning here, which is a fancy way of saying we follow a specific set of rules to decide how to bump those numbers. Basically, it's a system that helps everyone understand the scope of the changes in a release just by looking at the version number. Semantic Versioning is essential for communicating the impact of changes to users and developers. For example, 4.1.3 tells us this is a patch release (bug fixes), while 4.2.0 would indicate new features, and 5.0.0 would mean there are breaking changes. Understanding these nuances is super important for managing dependencies and expectations.

• [ ] Update this ticket name to reflect the new version number, following the pattern "Release 4.x.x".

  • Keeping the ticket name updated is all about staying organized. It helps everyone involved quickly see what version we're talking about. Think of it as labeling your folders on your computer – makes life a whole lot easier! A clear ticket naming convention is crucial for issue tracking and project management. It allows teams to easily identify and reference specific releases, ensuring that discussions and updates are always in the correct context. This simple step can save a lot of time and prevent confusion.

• [ ] Update allprojects.version string (Eg: 4.x.x) attribute in the build.gradle.kts file.

  • This is a bit more technical, but it's about making sure the version number is correctly set in our build configuration file. This file tells our build system (Gradle) what version we're building. Updating the build configuration file ensures that the correct version number is baked into the application. This is vital for version tracking and dependency management. Imagine releasing an update with the wrong version number – chaos would ensue! So, this step is a must-do.

• [ ] Code freeze and cut a branch for the new release out of the develop branch, following the Gitflow naming pattern release/4.x.x.

  • Okay, code freeze! This means no more new features going into this release. We're stabilizing the code and getting it ready to ship. Then, we create a new branch (like a copy of our code) specifically for this release. This keeps our main development branch clean and allows us to work on the release separately. Code freeze and branching are fundamental practices in software development. Freezing the code ensures stability and allows for focused testing and bug fixing. Creating a release branch allows for parallel development and maintenance, preventing disruptions to ongoing development efforts.

• [ ] Update the badges versions in [docs/README.md].

  • Badges are those little images you often see on GitHub repos that show things like the build status or version number. We need to update them to reflect the new release. It's all about keeping things consistent and giving people accurate information at a glance. Updating badges is a small but important step in maintaining a professional and informative repository. It provides visual cues about the project's status and helps users quickly understand key information, such as the current version or build status.

• [ ] In general, only bug fixes and security patches will be applied to the release/4.x.x branch.

  • This is a rule of thumb for release branches. We want to keep them stable and focused on fixing issues, not adding new features. Think of it as patching up a tire – you're not going to redesign the whole wheel! This focus on stability is crucial for maintaining the integrity of the release. Introducing new features into a release branch can lead to unexpected issues and delays. By limiting changes to bug fixes and security patches, we minimize the risk of regressions and ensure a more reliable release.

Release Publication

Alright, we've prepped everything, now it's showtime! Release publication is the moment we make the new version available to the world. Let's walk through the steps to make sure it goes off without a hitch.

• [ ] DO NOT RELEASE before holidays or weekends! Mondays and Tuesdays are preferred.

  • This might seem a bit random, but it's actually a smart move. Releasing mid-week gives us time to react to any issues that might pop up. If we release on a Friday, and something goes wrong over the weekend, we're in trouble! This strategic timing of releases is a practical consideration. By avoiding releases before weekends or holidays, teams can ensure that there are enough resources available to address any potential issues. It's all about minimizing risk and ensuring a smooth experience for users.

• [ ] Create a new release draft on GitHub with the name 4.x.x and tag: 4.x.x (without the release- prefix).

  • GitHub releases are a great way to package up our code and make it available for download. Creating a draft gives us a chance to review everything before we make it public. GitHub Releases provide a structured way to distribute software and communicate changes to users. Creating a draft allows for review and refinement before the release is made public, ensuring that all information is accurate and complete.

• [ ] Write the proper release notes.

  • Release notes are super important! They tell people what's new, what's changed, and what's fixed in this release. Think of them as the instruction manual for the new version. Clear and informative release notes are essential for user adoption and satisfaction. They provide a concise summary of the changes in the release, allowing users to quickly understand the value of the update. Well-written release notes can also help users troubleshoot issues and avoid common pitfalls.

  • [ ] Use Generate release notes in the GitHub UI to generate the changes.

    • GitHub can automatically generate release notes based on the commit history. It's a great starting point, but we'll need to clean them up a bit. This automated generation of release notes can save a lot of time and effort. However, it's important to review and edit the generated notes to ensure that they are accurate and comprehensive.

  • [ ] Remove chore and refactor commits from the release notes. (eg. merge to develop, version bump, etc.)

    • We want to focus on the changes that users will care about, not the behind-the-scenes stuff. Chore commits (like updating dependencies) and refactor commits (code cleanup) are important, but they don't need to be in the release notes. Focusing on user-facing changes makes the release notes more concise and relevant. Users are primarily interested in new features, bug fixes, and other changes that directly impact their experience. Removing irrelevant commits ensures that the release notes are easy to read and understand.

  • [ ] Add What's New section if applicable.

    • If there are any exciting new features in this release, highlight them! This is a great way to get people excited about the update. A What's New section is a great way to showcase the most significant changes in the release. It allows users to quickly grasp the key improvements and encourages them to try out the new features.

  • [ ] Add What's Changed section if applicable.

    • This section covers any changes to existing features or functionality. It's important to let people know if anything has been modified, even if it's not a brand-new feature. A What's Changed section provides a comprehensive overview of all modifications in the release. This is crucial for users who are familiar with the previous version and need to understand how the update will affect their workflow.

  • [ ] Add Bug Fixes section if applicable.

    • Everyone loves bug fixes! This section lists all the bugs that have been squashed in this release. Knowing that issues have been resolved can give users confidence in the update. A Bug Fixes section demonstrates the team's commitment to quality and responsiveness to user feedback. It provides transparency about the issues that have been addressed and reassures users that their concerns are being taken seriously.

• [ ] After reviewing the release draft, publish!!!

  • The moment of truth! Once we've reviewed everything and we're happy with it, we can hit that publish button and share the new release with the world. Publishing the release is the culmination of all the preparation and effort. It's a rewarding moment to see the new version out in the wild, ready for users to enjoy.

Post Release Publication

We've published the release, but our job isn't done yet! There are still a few things we need to do to make sure everything is running smoothly. Post-release publication activities are crucial for ensuring a successful and well-maintained release.

• [ ] Check the docker image of the release automatically published to Docker Hub.

  • Docker images are a way of packaging up our application and all its dependencies into a single, portable unit. We need to make sure the Docker image for this release has been built and published correctly. Verifying the Docker image ensures that the application can be easily deployed and run in various environments. It's a critical step in the release process, especially for applications that are designed to be containerized.

• [ ] If necessary, update the badges versions in [docs/00 - Stellar Anchor Platform.md].

  • We updated the badges in the main README, but there might be other places where we need to update them as well. Consistency is key! Maintaining consistent badges across all documentation and repositories is important for providing accurate and up-to-date information to users. It helps users quickly understand the status and version of the project.

• [ ] Create the pull request release/4.x.x -> main: this should require two approvals. DO NOT squash merge.

  • Now we need to merge the release branch back into our main branch. This is how we integrate the changes into the main codebase. Requiring two approvals adds an extra layer of review to make sure everything is in order. Merging the release branch into the main branch integrates the changes into the main codebase, making them available for future releases. The requirement for two approvals ensures that the merge is carefully reviewed and that any potential issues are identified and addressed.

• [ ] Create another pull request release/4.x.x -> develop: AFTER the release branch is merged with the main branch. DO NOT squash merge.

  • We also need to merge the release branch back into our development branch. This ensures that our development branch stays up-to-date with the latest changes. Keeping the development branch synchronized with the release branch is important for ensuring that future development efforts are based on the latest codebase. It prevents divergence and makes it easier to integrate new features and bug fixes.

• [ ] Publish the new version in the #release Slack channel.

  • Let everyone know about the new release! This is a great way to keep the community informed and engaged. Communicating the release to the relevant channels ensures that stakeholders are aware of the new version and can take advantage of the updates. It's a crucial step in promoting adoption and gathering feedback.

• [ ] (Optional) Generate the new Anchor Platform documentation version in the stellar-docs repository if this is a new major or minor version.

  • If this is a big release (a major or minor version), we might need to update the documentation as well. This ensures that users have access to the latest information about the platform. Updating documentation is essential for providing users with the information they need to effectively use the software. It's especially important for major and minor releases, which often include significant changes that need to be documented.

• [ ] (Optional) You'll need to manually publish a new version of the SDK to Maven Central in the legacy/release-1.0.

  • If we've made changes to the SDK (Software Development Kit), we need to publish a new version to Maven Central, which is a repository where developers can download libraries and tools. This makes our SDK available to other developers who want to use it. Publishing the SDK ensures that developers have access to the latest version of the tools they need to build applications on the platform. It's a critical step in promoting adoption and fostering a healthy ecosystem.

So there you have it! Everything you need to know about releasing version 4.1.3 of the Stellar Anchor Platform. It might seem like a lot of steps, but each one is important for ensuring a smooth and successful release. Keep this guide handy, and you'll be a release master in no time!