Skip to content

Commit b0a2f37

Browse files
astrapisixtynineastrapisixtynine
committed
docs(design): annotate v0.7.0 doc with v0.8.0 deferral note
The v0.7.0 design doc described the v0.8.0 hard-filter enforcement in future tense throughout (Decision 4 Migration, Behavior Matrix v0.8.0 column, Q2/Q4 resolutions). v0.8.0 became a stability release instead, deferring the enforcement to v0.9.0. Added a post-release note at the top of the file calling out the deferral. The body of the document is left unrevised: design docs are records of intent at a point in time, not living specs, so annotating without rewriting preserves the historical context. Concrete consumers of this disposition (Wiki Lifecycle, BasePlugin, Roadmap, Changelog) were updated separately in the wiki to reflect the deferred timeline. CLAUDE.md and the in-repo guides (consumer-integration, plugin-author) needed no changes.
1 parent 360b349 commit b0a2f37

1 file changed

Lines changed: 9 additions & 0 deletions

File tree

‎docs/design/v0.7.0-application-identity.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,15 @@
66
**Reviewers:** PluginForge maintainers, downstream consumer agents (Bibliogon, AdaptivLearner, third-party)
77
**Tracking issue:** [#1](https://github.com/astrapi69/pluginforge/issues/1)
88

9+
> **Post-release note (2026-05-20):** The "v0.8.0 enforcement" behavior
10+
> described below as future-tense (Decision 4 Migration, the Behavior
11+
> Matrix v0.8.0 column, Q2/Q4 resolutions, etc.) did NOT ship in v0.8.0.
12+
> v0.8.0 shipped with the v0.7.0 warning behavior preserved; the
13+
> hard-filter transition is deferred to v0.9.0. See the Roadmap and
14+
> CHANGELOG for the actual v0.8.0 contents. This document is left
15+
> unrevised as a record of what was planned at the time the v0.7.0
16+
> implementation shipped.
17+
918
## Context
1019

1120
PluginForge today has no concept of which application a plugin targets. The de facto isolation mechanism (entry-point group separation via `plugins.entry_point_group` in `app.yaml`) is a publishing convention, not an enforced invariant. A plugin can register under multiple groups, a plugin's own code cannot assert which application it targets, and a user pip-installing a plugin from a wrong source has no protection.

0 commit comments

Comments
 (0)