tbonelee opened a new pull request, #5284:
URL: https://github.com/apache/zeppelin/pull/5284

   ### What
   
   Resolves ZEPPELIN-6501. Rather than refreshing the hardcoded version numbers 
in `AGENTS.md`, this **removes the version literals and points each one to its 
source of truth**, so the file cannot drift again.
   
   Changed spots: Project Overview (Language, Frontend, Version) and the 
Contributing → Prerequisites table (JDK, Maven, Node.js).
   
   | Value | Now references |
   |-------|----------------|
   | Java / Scala | root `pom.xml` (`java.version`, `scala.binary.version`) |
   | Project version | root `pom.xml` `<version>` |
   | Frontend (Angular / Node) | `zeppelin-web-angular/package.json` 
(`engines.node`, `@angular/core`); Node build pin in `pom.xml` (`node.version`) 
|
   | Maven | `.mvn/wrapper/maven-wrapper.properties` (the `./mvnw` wrapper pins 
it) |
   
   ### Why reference instead of updating the numbers
   
   The listed values had already drifted — the frontend was documented as 
**Angular 13 / Node 18** but is actually **Angular 21 / Node ≥22.12**. Simply 
bumping them to today's values would recreate the same problem at the next 
upgrade: a second copy that quietly goes stale (which is exactly why this issue 
exists).
   
   `AGENTS.md` is read primarily by **AI coding agents** (and new 
contributors). For that audience a **single source of truth is worth more than 
the convenience of seeing the number inline on one page** — an agent can open 
`package.json` / `pom.xml` in one step, whereas a stale literal actively 
misleads it into wrong build instructions. So the doc now keeps the *pointer* 
and lets the canonical file own the *value*.
   
   Editorial guidance that is not itself a version literal is preserved (e.g. 
"use exactly that JDK major, not a newer/older one").
   
   ### Notes
   
   - `CLAUDE.md` is a symlink to `AGENTS.md`, so it is covered automatically.
   - Docs-only change; no build/test impact.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to