Files
LangBot/plugins/RELEASING.md
T

63 lines
2.6 KiB
Markdown

# Independent plugin releases
Core and plugins share a source checkout, not a release train. Never add plugin
dependencies to Core's `pyproject.toml`, bundle plugin sources in Core artifacts,
or use a Core release event to publish plugins.
## Develop and test
Choose one plugin from [catalog.json](catalog.json). Run its tests in its own
environment following its README. CI entrypoints are the five `plugins-*-tests`
workflows and the catalog workflow in `../.github/workflows/`; they preserve the existing
published SDK baselines and independent interpreters. LocalAgent and the Runner
test harness intentionally use different SDK pins. Do not merge their lockfiles.
From the repository root:
```sh
python plugins/scripts/check_catalog.py
python plugins/scripts/test_repository.py
```
## Build only
Run the **Plugins / Build package** workflow manually, selecting a relative
catalog path such as `Runner/LocalAgent` or `misc/HelloPlugin`. It builds only
that plugin and uploads an unsigned `.lbpkg` artifact. It neither creates a
GitHub release nor contacts Marketplace. Review the selected revision and test
results before requesting publication.
The equivalent local flow, using an independently installed SDK CLI, is:
```sh
cd plugins/misc/HelloPlugin
lbp build
```
The repository root and the `plugins/` root are not plugin packages. Never run
`lbp build` or `lbp publish` from either root.
## Marketplace publication
The existing per-plugin SDK flow remains unchanged:
1. Review the plugin tests, compatibility, release notes and certification
requirements. Increment that plugin's manifest version, and its project
version where applicable; do not change Core's version.
2. Keep `metadata.author`, `metadata.name` and component IDs stable. Update the
catalog with `python plugins/scripts/check_catalog.py --write` from the root.
3. In an authorized maintainer environment, use `lbp login` and then run
`lbp publish` from the selected plugin directory. Do not place credentials
in the repository or give them to pull-request jobs.
4. Follow the Marketplace draft/review flow and verify the resulting plugin
version and an upgrade from the prior version in a test Workspace.
No Marketplace submission or existing listing is changed by a source merge.
Moving a repository link changes newly built bytes; previous artifact evidence
must not be treated as certification of the new archive.
If GitHub release assets are also needed, use an explicit plugin namespace such
as `plugins/HelloPlugin/v0.1.1` and upload only that plugin's package. Core release
workflows reject plugin-prefixed release tags; they must not publish Core for a
plugin release.