Skip to content

Explore release automation with Apache Trusted Releases and weekly candidates #303

Description

@tisonkun

Motivation

Reduce the manual work in the Asyncband release lifecycle by exploring Apache Trusted Releases (ATR) integration and a weekly release attempt when new commits are available.

Asyncband already uses crates.io Trusted Publishing for approved final tags. This work concerns candidate preparation, source-artifact signing and staging, voting, and the handoff to that existing publication workflow.

OpenDAL provides useful references: weekly candidate preparation, ATR composition, and release lifecycle synchronization. Adapt the relevant parts to Asyncband's release process.

Scope to explore

  • Define a weekly source cutoff and comparison baseline. Skip runs without new commits and avoid duplicate candidates when a release is already being prepared or voted on. Decide how to handle new commits during an active vote.
  • Prepare a reviewable version and changelog update, including pre-1.0 breaking changes, using the existing cargo x checks and semver workflow.
  • Evaluate ATR Trusted Publishing: reproducible artifacts, project signing keys, and permitted compose/vote/finish workflows. Its ASF configuration is separate from the already configured crates.io OIDC publishing.
  • Preserve the Incubator's PPMC and IPMC approval process. Verify ATR's two-round podling workflow and the remaining release-manager decisions; OpenDAL's PMC workflow is not a direct substitute.
  • Track the source and release commits, version, RC tag, artifact digests, and ATR revision. Retries should resume the same candidate and retain the exact voted artifacts.
  • Evaluate ATR staging and approved source publication, then connect successful IPMC approval to the final tag and protected crates.io publication. Handle partial successes before retrying.

Proposed delivery

Start with a manually runnable candidate workflow and establish the required ASF configuration, then add the weekly schedule and lifecycle integration. Return a useful handoff containing verification results, candidate links, and the next release-manager action.

Validate unchanged source, overlapping runs, active or rejected candidates, and partial publication failures. Update the release skill to describe the implemented workflow and recovery path. Scheduling should initiate a release attempt while retaining community review and the required votes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions