[Proposal] Cloudberry Open Source Release Plan for Version 1.6.0

[edespino]

Proposers

@edespino

Proposal Status

Under Discussion

Abstract

This proposal outlines the plan for the next Cloudberry Open Source Release, version 1.6.0, scheduled for release on September 3rd. The release will involve creating REL_1_STABLE branches across multiple repositories, with the goal of producing stable release artifacts, including source tarballs and convenience binaries (RPMs for el8 & el9). Additional components will be included as stretch goals.

Motivation

• Consistency: Establish a clear and consistent release process across all major repositories within the Cloudberry project.
• Stability: Ensure that the release is thoroughly tested and validated, providing a stable version for users.
• User Accessibility: Provide well-packaged release artifacts, making it easier for users to install and use the latest version of Cloudberry.

Implementation

1. Repositories and Branching Strategy

• Repositories Involved:

  • cloudberrydb
  • pxf
  • gpbackup
  • gpbackup-s3-plugin
  • filedump

• Branch Creation:

  • Create REL_1_STABLE branches from the main branch in each repository listed above.
  • Ensure the main branch is stable before branching.

• Stretch Goal Repositories:

  • plr
  • pljava
  • madlib

  These repositories will be included in the release if time and resources allow.

2. Release Artifacts

• Source Tarballs:

  • Create source tarballs from each repository's REL_1_STABLE branch.
  • Ensure all necessary files are included for building the project.

• Convenience Binaries:

  • Build RPM packages for el8 and el9 from the REL_1_STABLE branches.
  • Validate the binaries and ensure they are signed before release.

3. Testing and Validation

• Unit Testing: Perform unit tests on the REL_1_STABLE branches to ensure code stability.
• Integration Testing: Conduct integration testing across components to ensure interoperability.
• Binary and Source Validation: Confirm that RPM binaries are installable and functional, and that source tarballs can build the project.

4. Documentation and Communication

• Release Notes: Prepare detailed release notes for version 1.6.0, including new features, bug fixes, and known issues.
• User Documentation: Update all relevant documentation to reflect changes in version 1.6.0.
• Communication: Announce the release plan internally and prepare a public announcement for the Cloudberry community.

5. Rollout/Adoption Plan

• Internal Rollout: Begin with an internal rollout to test environments.
• Public Release: Publish the source tarballs and RPM binaries on September 3rd.
• Post-Release Support: Monitor the release for issues and provide support for upgrades.

Rollout/Adoption Plan

1. Internal Rollout:

   • Begin by rolling out the release internally to test environments to catch any last-minute issues.

2. Public Release:

   • On September 3rd, publish the source tarball and RPM binary artifacts on the Cloudberrydb project’s GitHub Release page.
   • Announce the release publicly via the Cloudberry community channels, mailing lists, and social media.

3. Post-Release Support:

   • Monitor the release for any critical issues and be prepared to issue hotfixes if necessary.
   • Provide support to the community and users as they upgrade to version 1.6.0.

[my-ship-it]

Thanks for the proposal. The plan LGTM

[jianlirong]

From a content perspective, this proposal places more emphasis on the fact that, starting from Version 1.6, we will have a new, more defined, and solid product baseline (what kinds of basic modules and functions must be included). However, there is not much mention of the new features added in Version 1.6 compared to the previous version, Version 1.5.4. Should we add this part of content here, or should we discuss it in a separate thread?