|
1 | 1 | # Release extensions |
2 | 2 |
|
3 | 3 | Release Gemini CLI extensions to your users through a Git repository or GitHub |
4 | | -Releases. |
| 4 | +Releases. This guide explains how to share your work, list it in the gallery, |
| 5 | +and manage updates. |
5 | 6 |
|
6 | 7 | Git repository releases are the simplest approach and offer the most flexibility |
7 | 8 | for managing development branches. GitHub Releases are more efficient for |
@@ -153,29 +154,62 @@ jobs: |
153 | 154 | release/win32.arm64.my-tool.zip |
154 | 155 | ``` |
155 | 156 |
|
156 | | -## Migrating an Extension Repository |
| 157 | +## Migrate an extension repository |
157 | 158 |
|
158 | | -If you need to move your extension to a new repository (for example, from a |
159 | | -personal account to an organization) or rename it, you can use the `migratedTo` |
160 | | -property in your `gemini-extension.json` file to seamlessly transition your |
| 159 | +If you move your extension to a new repository or rename it, use the |
| 160 | +`migratedTo` property in `gemini-extension.json` to seamlessly transition your |
161 | 161 | users. |
162 | 162 |
|
163 | | -1. **Create the new repository**: Setup your extension in its new location. |
164 | | -2. **Update the old repository**: In your original repository, update the |
165 | | - `gemini-extension.json` file to include the `migratedTo` property, pointing |
166 | | - to the new repository URL, and bump the version number. You can optionally |
167 | | - change the `name` of your extension at this time in the new repository. |
168 | | - ```json |
169 | | - { |
170 | | - "name": "my-extension", |
171 | | - "version": "1.1.0", |
172 | | - "migratedTo": "https://github.com/new-owner/new-extension-repo" |
173 | | - } |
174 | | - ``` |
175 | | -3. **Release the update**: Publish this new version in your old repository. |
176 | | - |
177 | | -When users check for updates, Gemini CLI will detect the `migratedTo` field, |
178 | | -verify that the new repository contains a valid extension update, and |
179 | | -automatically update their local installation to track the new source and name |
180 | | -moving forward. All extension settings will automatically migrate to the new |
181 | | -installation. |
| 163 | +1. **Create the new repository:** Set up your extension in its new location. |
| 164 | +2. **Update the old repository:** In your original repository, update the |
| 165 | + `gemini-extension.json` file to include the `migratedTo` property pointing |
| 166 | + to the new repository URL, and increment the version number. |
| 167 | + ```json |
| 168 | + { |
| 169 | + "name": "my-extension", |
| 170 | + "version": "1.1.0", |
| 171 | + "migratedTo": "https://github.com/new-owner/new-extension-repo" |
| 172 | + } |
| 173 | + ``` |
| 174 | +3. **Release the update:** Publish this new version in your old repository. |
| 175 | + |
| 176 | +When users check for updates, Gemini CLI detects the `migratedTo` field, |
| 177 | +verifies the new repository, and automatically updates their local installation |
| 178 | +to track the new source. All settings migrate automatically. |
| 179 | + |
| 180 | +## How updates work |
| 181 | + |
| 182 | +Gemini CLI automatically checks for extension updates based on the installation |
| 183 | +method. Understanding these mechanisms helps you ensure your users always have |
| 184 | +the latest version. |
| 185 | + |
| 186 | +### Sync manifest and tags |
| 187 | + |
| 188 | +For GitHub releases, always ensure the `version` in `gemini-extension.json` |
| 189 | +matches your GitHub release tag. While the CLI uses tags for update detection, |
| 190 | +it displays the manifest version in the UI. Keeping them in sync prevents |
| 191 | +confusion. |
| 192 | + |
| 193 | +### Update mechanisms |
| 194 | + |
| 195 | +<details> |
| 196 | +<summary>Technical update details</summary> |
| 197 | + |
| 198 | +The CLI uses different strategies depending on the installation type: |
| 199 | + |
| 200 | +- **GitHub releases:** The CLI queries the GitHub API for the latest release |
| 201 | + tag. It ignores the `version` field in the manifest for detection. |
| 202 | +- **Git clones:** The CLI runs `git ls-remote` to compare the latest remote |
| 203 | + commit hash with your local `HEAD`. |
| 204 | +- **Local extensions:** The CLI compares the `version` field in the source |
| 205 | + directory's manifest with the installed version. |
| 206 | + |
| 207 | +To verify an extension's installation type, inspect the `type` field in the |
| 208 | +metadata file at `~/.gemini/extensions/<name>/.gemini-extension-install.json`. |
| 209 | + |
| 210 | +</details> |
| 211 | + |
| 212 | +<!-- prettier-ignore --> |
| 213 | +> [!IMPORTANT] |
| 214 | +> The `migratedTo` flow requires at least one release on the new repository for |
| 215 | +> the CLI to recognize it as a valid update source. |
0 commit comments