Hi Zihan, Thanks for bringing these to the list — and for laying out the externals reasoning up front, which makes the tradeoff much clearer than a bare version bump would.
**1. Minimum supported Grafana version** I agree the declaration should match what we actually test. Since `@grafana/*` resolves from the host Grafana at runtime, a "declared but unverified" floor is effectively no guarantee at all. I'd suggest **option 1 — follow the toolchain**: raise to `>=12.3.0` (or whatever the current scaffold's devDependencies track), document the compatibility change in the plugin README and release notes, and add a CI smoke test that boots the *minimum* declared Grafana version and verifies the plugin loads and runs a table-model query. The smoke test is the part that makes either choice trustworthy, so please keep it in #118 regardless. The alternative — pinning the `@grafana/*` devDependencies to the oldest version we intend to support — is more maintenance and partly defeats the purpose of the migration, so I wouldn't choose it unless there's a concrete user need we'd otherwise break. Dropping Grafana 9/10/11 users of an already-released plugin is a compatibility decision, so I'd like to give the community a chance to object. **If there are no objections by end of 2026-08-06 (Thursday) UTC, I'll merge #118 with option 1.** **2. AGENT-instruction files** I'd drop them from the PR and gitignore them. A checked-in, scaffold-generated instruction set that tells contributors "do not modify this folder" sits awkwardly with the expectation that everything in an ASF repository is governed by the project — and since `.config` is regenerated by the scaffold anyway, carrying it adds a maintenance surface without adding governance value. If the community later develops a policy on agent-facing files, we can revisit deliberately rather than inherit it as a toolchain side effect. Same deadline applies: no objections by 2026-08-06 → #118 lands without them. **3. LICENSE / RAT coverage for the grafana-plugin module** This one I'll fold into #118 as a fix regardless. The module is the only one in this repo carrying its own LICENSE, yet it's excluded from apache-rat in the connectors pom, and no Maven job builds it in the default connectors profile. With the dependency set changing wholesale (+69/−18), I'd like to: - bring the grafana-plugin tree back into RAT (or add a dedicated license check), and - give the module a Maven/CI path that actually builds it (it currently only appears under the `with-grafana-plugin` profile). Zihan, happy to have you implement these per the above; if the community prefers a different direction on 1 or 2, speak up before 2026-08-06. Best, Xuan Wang Zh D <[email protected]> 于2026年8月3日周一 20:43写道： > Hi all, > > While migrating the Grafana data source plugin off the archived > @grafana/toolkit onto @grafana/create-plugin (iotdb-extras PR #118), > two questions came up that I do not think I should decide inside the > PR. Xuan Wang raised both in review and suggested bringing them here. > Neither blocks the migration itself. > > 1. Minimum supported Grafana version > ------------------------------------ > > The migration regenerates the plugin against the current scaffold, and > the question is what to declare in plugin.json. Today it says > > "grafanaDependency": ">=9.3.0" > > and the PR currently proposes > > "grafanaDependency": ">=12.3.0" > > The technical situation: the @grafana/* packages are webpack externals, > resolved from the host Grafana at runtime rather than bundled. So a > plugin built against 13.x that calls a newer @grafana/ui or > @grafana/data API does not fail to build against an older host -- it > builds fine and then fails inside the user's Grafana, with no bundled > fallback. In that sense a floor we have not tested is not really a > supported floor. > > The cost is the part that is not mine to decide: raising it drops > Grafana 9, 10 and 11 users of an already-released Apache plugin. That > is a project compatibility decision rather than a build detail. > > The alternative, if the PMC prefers to keep a lower floor, is to pin > the @grafana/* devDependencies down to the oldest version we intend to > support instead of tracking the scaffold, and keep the declared > dependency where it is. That is more maintenance but it makes the > declared floor real rather than nominal. > > I have no strong preference and will implement whichever the PMC > decides. > > 2. Agent-instruction files emitted by the scaffold > -------------------------------------------------- > > @grafana/create-plugin now generates a .config/AGENTS/ directory -- > four files, 316 lines (instructions.md, e2e-testing.md and two files > under skills/). They are vendor-neutral Grafana content: they describe > how to build, validate and e2e-test a plugin, and point at Grafana's > own published component documentation. Nothing in them is specific to > any AI vendor, and nothing claims authorship of our code. > > Two things about them are worth a conscious decision rather than > arriving as a side effect of a toolchain bump: > > - They are instructions directed at an automated agent, checked into > an ASF repository. As far as I can tell that is new ground for > this project. > > - instructions.md lists under "Critical rules": "Do not modify > anything inside the .config folder. It is managed by Grafana > plugin tools." A checked-in file telling contributors not to > modify part of the tree sits a little awkwardly next to the usual > expectation that everything in the repository is governed by the > project. In practice .config is regenerated by the scaffold, so > the rule is descriptive rather than a real restriction -- but I > would rather have that said out loud than assumed. > > They can be dropped from the PR and gitignored if the project would > rather not carry them; the build does not depend on them. > > Related, and the reason I am asking now rather than later: the > migration replaces the dependency set wholesale -- package.json > changes by +69/-18 and yarn.lock (11,348 lines) is replaced by > package-lock.json (16,642 lines). > > connectors/grafana-plugin/ is the only module in this repository that > carries its own LICENSE; NOTICE files live at the root and cover the > project as a whole. That file is unchecked twice over: the connectors > pom excludes the grafana-plugin tree from apache-rat, and no CI job > builds this module through Maven at all, since it sits in the separate > with-grafana-plugin profile rather than with-all-connectors. Given the > scale of the dependency change it seems worth confirming whether that > LICENSE needs a pass, even though these are devDependencies and are > not shipped in the plugin artifact. > > Happy to do the work either way on any of these -- I am asking for > the direction, not for someone else to pick it up. > > Best regards, > Zihan Dai > GitHub: PDGGK >
