Skip to content

docs(releasekit): adopt release-please model - #4575

Merged
yesudeep merged 4 commits into
mainfrom
releasekit-roadmap
Feb 11, 2026
Merged

yesudeep merged 4 commits into
mainfrom
releasekit-roadmap

Conversation

@yesudeep

@yesudeep yesudeep commented Feb 11, 2026 •

Copy link
Copy Markdown
Contributor

Roadmap Update: Release-Please Model & Independent Versioning

This PR refactors the releasekit roadmap to adopt a Release-Please style workflow and introduces a robust Independent Versioning strategy for the monorepo.

Key Changes

  1. New Lifecycle Commands (replaces monolithic pipeline)

    • prepare: Scans commits, computes bumps (with transitive propagation), updates pyproject.toml/lockfiles, generates changelogs, and creates/updates a Release PR with an embedded manifest.
    • tag: Triggered on Release PR merge. Parses the manifest, tags the merge commit, and creates a GitHub Release.
    • publish: Triggered on Release creation. Builds with ephemeral pinning, uploads to PyPI, and dispatches to downstream repos.
  2. Versioning Strategy

    • Independent (Default): Packages bump based on their own commits.
      • Transitive Propagation: ANY bump in a dependency triggers a PATCH bump in all dependents. This ensures lockfiles are updated and fresh pins are used. Releases ripple through the dependency tree.
    • Synchronized (Lockstep): Optional mode (synchronize = true) where all packages share the same version.
    • D-11 Updated: Transitive propagation is now supported as PATCH bumps only (not matching the original bump type), avoiding the changesets #1011 problem.
  3. Cross-Repository Support

    • Main repo fires repository_dispatch after publish.
    • Downstream repos run releasekit prepare, which detects external updates via uv lock --upgrade-package.
  4. Contradictions Resolved

    • Removed all commitback.py references (replaced with prepare.py + release.py).
    • Pipeline rewritten from monolithic 9-step to 3-command split.
    • Phase 5 renamed from "Post-Pipeline" to "Release-Please".
    • Mermaid diagram updated with preparemod + releasemod nodes.
    • versioning.py description updated to reflect transitive propagation + synchronize mode.
    • File tree updated with new modules and test files.

Architecture

Dependency Tree Propagation

       [genkit]  v0.5.0 → v0.6.0  (Minor Bump: "feat: core update")
          │
          ▼
   [genkit-plugin-vertex-ai]
   Depends on: genkit
   Action: v0.5.0 → v0.5.1  (Patch Bump)
   Reason: "dependency genkit bumped"
          │
          ▼
     [sample-app]
     Depends on: genkit-plugin-vertex-ai
     Action: v0.1.0 → v0.1.1  (Patch Bump)
     Reason: "dependency genkit-plugin-vertex-ai bumped"

Release Lifecycle

   Developer
      │
      │ pushes to main
      ▼
 ┌───────────────────────────────────────────────────────────────┐
 │ STEP 1: PREPARE (releasekit prepare)                          │
 │                                                               │
 │ 1. Scan commits per package                                   │
 │ 2. Compute bumps + Propagate to dependents (PATCH)            │
 │ 3. Update pyproject.toml & uv.lock                            │
 │ 4. Generate Changelogs                                        │
 │ 5. Create/Update "Release PR" (autorelease: pending)          │
 └───────────────────────────────────────────────────────────────┘
      │
      │ merges Release PR
      ▼
 ┌───────────────────────────────────────────────────────────────┐
 │ STEP 2: TAG (releasekit tag)                                  │
 │                                                               │
 │ 1. Find merged PR with "autorelease: pending"                 │
 │ 2. Parse Manifest from PR Body                                │
 │ 3. Tag Merge Commit (per-pkg + umbrella tags)                  │
 │ 4. Create GitHub Release                                      │
 │ 5. Label PR "autorelease: tagged"                             │
 └───────────────────────────────────────────────────────────────┘
      │
      │ triggered by Release creation
      ▼
 ┌───────────────────────────────────────────────────────────────┐
 │ STEP 3: PUBLISH (releasekit publish)                          │
 │                                                               │
 │ 1. Checkout Tag                                               │
 │ 2. Rewrite deps in pyproject.toml (Ephemeral Pinning)         │
 │ 3. Build Wheels/Sdists                                        │
 │ 4. Upload to PyPI                                             │
 │ 5. Label PR "autorelease: published"                          │
 │ 6. Dispatch "repository_dispatch" to downstream repos         │
 └───────────────────────────────────────────────────────────────┘

@github-actions github-actions Bot added docs Improvements or additions to documentation python Python labels Feb 11, 2026
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @yesudeep, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the documentation for releasekit, outlining its new approach to versioning and cross-repository dependency management. It clarifies how packages are versioned within monorepos and how external plugins can stay updated, reflecting a more robust and automated release process.

Highlights

  • ReleaseKit Versioning Models: Detailed the two versioning models for monorepos: Independent (default, transitive propagation) and Synchronized (lockstep, global bump).
  • Cross-Repository Plugin Workflow: Explained the process for managing external dependent packages, including repository_dispatch and releasekit prepare for dependency updates.
  • Documentation Structure Update: Removed the reference to commitback.py from the releasekit directory structure documentation.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog
  • py/tools/releasekit/roadmap.md
    • Added comprehensive sections detailing releasekit's independent and synchronized versioning strategies.
    • Introduced documentation for the cross-repository workflow for plugins.
    • Removed the entry for commitback.py from the file structure overview.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

@yesudeep
yesudeep enabled auto-merge (squash) February 11, 2026 08:45

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the releasekit roadmap to reflect the adoption of a Release-Please style workflow. The changes are well-documented and clearly explain the new versioning strategies and cross-repository workflow.

I've found a couple of areas in the new documentation that could be improved for clarity and consistency with the provided code context: a minor typo and a more significant inconsistency regarding how dependency updates trigger version bumps. My detailed comments are below.

Comment thread py/tools/releasekit/roadmap.md Resolved
Comment thread py/tools/releasekit/roadmap.md Resolved
@yesudeep
yesudeep disabled auto-merge February 11, 2026 09:03
- D-11: transitive PATCH propagation (not 'no propagation')
- Pipeline: rewritten as 3-command split (prepare/tag/publish)
- Phase 5: renamed to 'Release-Please', added prepare.py + release.py
- Mermaid: replaced commitbackmod with preparemod + releasemod
- versioning.py: supports transitive propagation + synchronize mode
- File tree: replaced commitback with prepare/release modules and tests
@yesudeep
yesudeep enabled auto-merge (squash) February 11, 2026 09:09
@yesudeep
yesudeep merged commit b700a54 into main Feb 11, 2026
19 checks passed
@yesudeep
yesudeep deleted the releasekit-roadmap branch February 11, 2026 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Improvements or additions to documentation python Python

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants