Principle:Mlflow Mlflow Release Automation
| Knowledge Sources | |
|---|---|
| Domains | Release Engineering, Automation |
| Last Updated | 2026-02-13 20:00 GMT |
Overview
Coordinated automation of release engineering tasks including patch cherry-pick verification, changelog generation, multi-language version synchronization, and time-based removal of provisional API markers.
Description
Releasing a new version of a multi-language project with a branching workflow involves several error-prone manual steps. This principle decomposes the release process into discrete automated tasks, each handling a specific concern.
Patch PR Verification ensures that all pull requests tagged for a patch release have been cherry-picked to the release branch. The system fetches commits from the release branch (within a recent time window), extracts PR numbers from commit messages, then compares these against the set of PRs labeled with the target version tag on the issue tracker. Any PRs that are labeled but not yet cherry-picked are identified and reported. The tool generates ready-to-run cherry-pick scripts, splitting into multiple scripts if the number of commits exceeds the CI platform's rebase merge limit. Each script includes a guard against accidentally running on the main branch.
Changelog Generation produces a structured release changelog by comparing the previous release tag against the current release branch. It uses git log with cherry-pick deduplication to identify new commits, extracts PR numbers from commit messages, fetches PR metadata in batches using a GraphQL API (title, author, labels), and categorizes each PR by its release note labels. The output is organized into sections: breaking changes, highlights, features, bug fixes, documentation updates, and a consolidated section for small updates grouped by author. PRs without release note labels are flagged as errors requiring categorization before the changelog can be finalized.
Version Synchronization updates version strings across all languages and configuration files in the project. A single command propagates a new version number to Python version files, TOML package configurations (including sub-package version pins), TypeScript constants, Java source files, Java POM XML files (with special handling to avoid accidentally modifying dependency version tags), and R package description files. Pre-release suffixes (dev, RC) are handled with language-appropriate transformations (e.g., "dev0" in Python becomes "-SNAPSHOT" in Java/Maven). The tool supports both pre-release (setting the release version) and post-release (bumping to the next dev version) workflows. A safety check prevents applying a version that would be a downgrade unless the current version is a release candidate.
Experimental Decorator Removal automates the graduation of provisional APIs to stable status. Functions decorated with an "experimental" marker that includes the version in which they were introduced are candidates for removal once a configurable time period has elapsed (default: six months). The system fetches release dates from the package index, parses all tracked Python files to find experimental decorators via AST analysis, computes the age of each decorator based on the release date of its associated version, and removes those that exceed the cutoff. Multi-line decorators are handled correctly by tracking start and end line numbers. A dry-run mode allows preview before modification.
Usage
This principle applies throughout the release lifecycle: during the stabilization phase (patch PR verification), at release time (changelog generation, version synchronization), immediately after release (post-release version bump), and periodically between releases (experimental decorator cleanup). Each tool can be run independently, and together they form a complete release workflow.
Theoretical Basis
The patch PR verification algorithm:
1. Derive the release branch name from the target version (branch-{major}.{minor})
2. Fetch commits from the release branch within the last 90 days
3. Extract PR numbers from commit messages matching the pattern "... (#NNNN)"
4. Fetch all PRs labeled "v{version}" from the issue tracker, excluding closed-not-merged
5. not_cherry_picked = labeled_PRs - branch_PR_numbers
6. For missing PRs:
a. Search the main branch for commits with matching PR numbers
b. Collect their SHAs for cherry-pick script generation
c. Split into chunks of <= 90 commits per script (platform limit)
d. Generate executable shell scripts with branch-safety guards
The changelog generation algorithm:
1. Fetch the previous release tag and the release branch
2. Run git log with --cherry-pick to find commits unique to the release branch
3. Extract PR numbers from commit message trailers
4. Batch-fetch PR metadata via GraphQL (title, author, labels)
5. Categorize PRs by release note labels:
- rn/breaking-change -> Breaking Changes section
- rn/highlight -> Major New Features section
- rn/feature -> Features section
- rn/bug-fix -> Bug Fixes section
- rn/documentation -> Documentation Updates section
- rn/none -> Small Updates (grouped by author)
- No label -> Error: must be categorized before proceeding
6. Assemble sections into a formatted changelog entry
7. Prepend the new entry to the existing changelog file
The version synchronization algorithm:
1. Read the current version from the canonical Python version file
2. For each language/file group, apply pattern-based replacement:
- Python: literal string replacement of old version with new
- TOML: regex replacement of version field, plus sub-package version pins
- TypeScript: literal string replacement
- Java source: replace version with dev-suffix transformation (dev -> -SNAPSHOT)
- Java POM XML: targeted replacement within specific XML tags only
- R DESCRIPTION: replace the Version field
3. For post-release: increment the micro version and append ".dev0"
The experimental decorator removal algorithm:
1. Fetch release dates for all project versions from the package index
2. For each tracked Python file:
a. Parse to AST
b. Walk all function, async function, and class definitions
c. For each @experimental(...) decorator:
- Extract the version keyword argument
- Look up the release date for that version
- Compute age_days = now - release_date
d. Filter to decorators where age_days > cutoff_days
e. Remove those decorator lines from the source file
(handling multi-line decorators via start/end line tracking)