Update extension-releasing.md to have more info #8927
Conversation
Adds information about the regular git release process as well as explaining some of the tradeoffs. Re-structure a bit the custom release section as well.
Summary of ChangesHello @jakemac53, 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 releasing Gemini CLI extensions by introducing and detailing two primary distribution methods: Git repositories and GitHub Releases. It provides guidance on managing release channels, explains the advantages and disadvantages of each method, and clarifies the structure and naming conventions for custom and platform-specific archives, ensuring users have a clearer understanding of their options for publishing extensions. Highlights
Using Gemini Code AssistThe 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
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 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
|
There was a problem hiding this comment.
Code Review
This pull request does a great job of expanding the documentation on extension releasing, adding a new section for git-based releases and restructuring the existing content for better clarity. The new information is valuable for extension developers. I've identified one statement in the new documentation that is factually incorrect about how extension updates work, which could mislead users. My review includes a specific suggestion to correct this.
|
Size Change: -2 B (0%) Total Size: 17.3 MB ℹ️ View Unchanged
|
docs/extension-releasing.md
Outdated
|
|
||
| This is the most flexible and simple option. Users can depend on any ref from your git repo, such as a branch or tag, which allows you to manage multiple release channels. You also can point at any git repository, so your extension does not have to be hosted on github. | ||
|
|
||
| For instance, you can maintain a `stable` branch, which users can install this way `gemini extensions install <your-repo-uri> --ref=stable`. Or, you could make this the default by treating your default branch as your stable release, and doing development in a different branch (for instance called `dev`). You can maintain as many branches or tags as you like, providing maximum flexibility for you and your users. |
There was a problem hiding this comment.
@chrstnb should we consider using the stable ref by default if it exists? This would allow people to use their main branch for development while not risking users accidentally depending on it (otherwise they have to do --ref=stable to be on the stable release channel).
In particular this can avoid issues around having to force push to your default branch if your history starts to diverge from your development branch due to cherry picks etc.
There was a problem hiding this comment.
I think the idea is that the github repo based approach is super simple and accessible. I'm wary of introducing a specific way of doing things yet.
There was a problem hiding this comment.
I am fine with that, I do worry this would be hard to change in the future though.
chrstnb
left a comment
There was a problem hiding this comment.
A couple comments but overall looks great
TLDR
Adds information about the regular git release process as well as explaining some of the tradeoffs.
Re-structure a bit the custom release section as well.
Dive Deeper
Reviewer Test Plan
Testing Matrix
Linked issues / bugs