mirror of
https://github.com/l0ng-ai/openidea.git
synced 2026-11-06 08:07:49 +00:00
l0ng-ai
953e844541
* feat(plugins): list community plugins from a registry in the marketplace The marketplace index can now carry plugins of other publishers, published from their authors' repositories through the l0ng-ai/openidea-plugins registry. - `openidea-plugin index` with a key replaces only that publisher's plugins (it used to drop every other entry); without a key it indexes each package against the publishers the index already lists, checking the key and the id prefix instead of only the signature itself. - `openidea-plugin merge` takes another index's publishers, plugins and revocations in place of every publisher but `--keep`; the other index can't list or revoke the kept publishers' plugins. - `openidea-plugin check` accepts a `.oiplugin` file. - Releases merge the registry's index into plugins-index.json and attach the Linux x64 tool; plugins-index.yml refreshes the community plugins in the latest release hourly or when the registry signals a change. - plugins/README.md and CONTRIBUTING.md describe official and community plugins. * feat(plugins): offer the newest plugin version this IDE can load Index entries record the plugin API each version needs (`engine`: the manifest's `engines.openidea` narrowed to the API its component was built for), and an index may list several versions of a plugin. Settings › Plugins offers the newest version this IDE can load; with none, the plugin is shown as incompatible with the API it needs, and downloading it is refused. `openidea-plugin index` keeps, of each plugin, the newest version per API requirement, so users of an older IDE keep the last version built for them; `--download-base` makes downloads absolute, and the release workflow points them at the release that published them. Scratch directories are now unique per call. * feat(plugins): file marketplace plugins under categories `plugin.toml` takes `categories` (up to 3 of languages, themes, icon-themes, linters, vcs, ai, frameworks, tools, other). A plugin that declares none is filed under what its contributions imply (themes, icon themes, languages), else under other; categories an IDE doesn't know are ignored, and `check` warns about them. Index entries carry the categories, and Settings › Plugins › Available filters by them and shows them in a plugin's details. The official plugins declare theirs. * feat(plugins): let a marketplace index point to where it moved An index with `moved` sends the IDE to the index at that URL (relative or absolute, up to three hops; an https index can only move to https). Downloads resolve against the index actually read, so a marketplace can change hosts while released IDEs keep the address they were built with. * fix(plugins): full-width category filter and aligned incompatibility note * fix(plugins): translate the AI category in Chinese * feat(plugins): keep a plugin's signer across updates and announce updates - Index format: fields are only added; an IDE reading a newer `format` still applies its revocations and `moved`, lists no plugins and asks to be updated, instead of failing to read the index. - Key continuity: an installed plugin updates silently only to a package signed with the same key, or a key it endorsed (`KeyEntry.endorsement`, `index --previous-key`, `openidea-plugin endorse`). Another signer, or an unsigned package replacing a signed one, is shown on the install page and needs the user's confirmation (`Consent.signerChange`). - Official key: release builds carry the official publisher's public key (`OPENIDEA_OFFICIAL_PLUGIN_KEYS`, derived from PLUGIN_SIGNING_KEY); `openidea.*` plugins must be signed with it or a key it endorsed, whatever the index lists. - Updates: the daily marketplace check announces new versions once, with Update All (also in the gear menu and as an action). An update that asks for nothing new installs with the grants the installed version has. - Index entries need `engine`; `categories` beyond the first three are ignored instead of rejecting the manifest.
2.0 KiB
2.0 KiB
Contributing to OpenIDEA
These rules apply to everyone, and to any coding agent working on their behalf. Project layout, coding rules, commands and checks are in AGENTS.md.
Issues
- One problem or request per issue. Use the issue forms.
- Bugs: steps that reproduce the problem from a fresh start. A minimal sample project is the fastest way to get a fix.
- Features: state the problem and the acceptance criteria. A feature is ready to
build once a maintainer labels it
planned. - Labels track status:
needs-infowaits on the reporter,needs-decisionwaits on a maintainer,plannedis accepted,needs-acceptancehas a fix waiting to be checked.
Pull requests
- One issue per PR, linked with
Closes #123. Feature PRs need aplannedissue. Docs, CI and pure refactors may skip the issue. - Reproduce the problem first, or write a test that fails before the fix.
- Fix the cause, and check whether the same cause breaks anything nearby.
- Keep the diff focused. Unrelated refactors go in their own PR.
- Title: Conventional Commits, e.g.
fix(editor): keep the caret visible after folding. - Fill in the template. Keep the description short and in plain words. If it doesn't fit in a few sentences, the PR is probably too big.
- How it was verified is required: the commands you ran and their results, and what else the change could affect. UI changes need before/after screenshots; multi-step interactions need a recording.
- If a change needs a product decision you can't make, ask in the issue and stop rather than guessing.
Plugins: pull requests here add or change official plugins (plugins/official/)
and the plugin API. Community plugins live in their authors' repositories and
are listed through l0ng-ai/openidea-plugins;
see plugins/README.md § 8.1.
A check on each PR adds needs-info when the issue link or the verification
section is missing, and removes it once they're filled in.