Regen Network shared details on Cosmos SDK launch

Regen Network shared last Thursday, October 7, through its Twitter account, the details about the update of the Cosmos SDK launch process.

“It has been almost a year and a half since the Regen Network engineering team stepped in as primary maintainers of the Cosmos SDK! With two big feature releases behind us, we thought it was time to provide some behind-the-scenes updates and share how we’ve updated our software development and release processes over the last 18 months for the SDK”, he said via an article. published on the Medium platform.

According to the company, as they moved into spring 2021, its engineering team was nearing completion of the implementation of the long-awaited feegrant and authz modules. These two features had been designed before Stargate, but due to bandwidth limitations, they decided to delay their implementation until after the release of version 0.40. In this way, they could build these two new modules directly on top of the more modern protobuf-based architecture of the SDK.

“As we got closer to feature completion for our next big SDK release, we decided to improve our release process with the goal of reducing required patches and security releases later. The hope was that with a more rigorous, formalized and anticipated internal audit process, we could lengthen the CR time. However, ultimately, we would raise the bar for the quality of the final version significantly and reduce the time spent on the RC phase”, he added.

Similarly, he commented that they accomplished this by introducing two new audit processes:

• A formalized ‘Module Readiness Checklist’, which each new SDK module must go through before being tagged in a published version.

• A ‘Release Quality Control Checklist’ to ensure thorough testing and quality of all changes made since the last major release (eg Stargate in the case of v0.43)

Module Readiness Checklists

In your view, for the module readiness checklists, we divided the audit into several different components and assigned individual team members to each:

• API Audit: ensure that the methods and types of messages and queries are well named, organized and well documented.

• State Machine Audit – Read all state machine code, ensure implementation matches specification, verify state machine extreme cases, and assess potential security risks or spam attack vectors.

• Integrity audit: ensure genesis import and export, query services, CLI methods, and migrations are fully implemented to completion.

Launch process and quality control

According to the company, while a good deal of feature development in the SDK happens within the context of the SDK modules, it is not all-encompassing! In the last few months, we’ve created workgroups and epics for the storage layer, transaction enhancements, and simplified application cabling. However, none of these fit this new module auditing model for “module readiness checklists”.

“For this reason, we have created a parallel structured process for more general version quality control. This process describes the main events in a publication process and establishes explicit checklists that must be completed along the way”, he highlighted.

Feature completeness

Once the feature is complete for a given version, the company indicated that they started the module readiness checklists for each new module that has been developed. Additionally, they performed a similar existing module audit for any changes to existing SDK modules since the last major release.

Beta labeling

The company indicated that once the previous audits have been completed, we are ready to tag a beta1 version of our master branch. Between any beta and rc version, we freeze the master branch of any kind of changes that break the state. Changes that break the client and small changes that break the API can still be merged into the master.

“From this beta label, we started a process of heavy manual simulations and testing. This includes running simulations in the cloud, testing all functions and fixes to the change log, and testing any migration from the existing state to the new state through chain updates of testnests. We are also trying to get some projects in the ecosystem to test an update to the beta version on their blockchain with their development team or validators”, he highlighted.

Also read: CheersLand announced partnership with Kangaroo Capital

Labeling an RC and final version

Once there is enough confidence in the beta version, the company instructed that they branch from the master into a version branch (for example, release / v0.43.x) and we tag a candidate version outside of the HEAD of that branch. Updates from here should focus on final bug fixes and polishes. RPs are merged into the master and must also be exported to the release branch if they are expected to go into release. Changes that break the client and small changes that break the API can still be merged into the version if deemed necessary.

“As a final step, we audit the complete change log with the commit log, ensuring that all major changes, bug fixes and enhancements are properly documented. We recommend running a final round of devnets and testnets for manual testing, focusing on any changes or bug fixes introduced since the last beta tag”, he said.