janhoy opened a new issue, #866:
URL: https://github.com/apache/solr-operator/issues/866
### Summary
Adopting a new Apache Solr release touches 14 files and ends with a
judgement call that nothing
checks. Encode the procedure as an Agent Skill in
`.agents/skills/solr-version-support/`, alongside
`dependency-upgrade`.
### Invocation
`/solr-version-support 9.11.0`, or prose ("adopt Solr 9.11"). The target
version is the only input.
If it is omitted, do not prompt blankly: list the Solr releases newer than
the current
`DefaultSolrVersion` and ask which to adopt. Validate before touching
anything — the tag must exist
on the official image, and a target older than the current default is a
downgrade to confirm, not a
typo to accept silently.
### The mechanical half
`DefaultSolrVersion` in `api/v1beta1/solrcloud_types.go:40` is the
operator-side default. The same
version string is then repeated, unchecked, in 13 other files — currently 21
occurrences of
`9.10.0`:
| File | Occurrences |
|---|---|
| `api/v1beta1/solrcloud_types.go` | 1 (`DefaultSolrVersion`) |
| `helm/solr/Chart.yaml` | 2 (`appVersion`, artifacthub example) |
| `helm/solr/README.md` | 3 |
| `helm/solr-operator/Chart.yaml` | 2 (`crdsExamples` for SolrCloud and
SolrPrometheusExporter) |
| `example/*.yaml` | 5, one each |
| `tests/scripts/manage_e2e_tests.sh` | 2 |
| `hack/release/smoke_test/test_cluster.sh` | 2 |
| `tests/e2e/suite_test.go` | 1 |
| `docs/modules/getting-started/pages/local-tutorial.adoc` | 3 |
| `dev-docs/e2e-testing.md` | 1 |
**No make target validates this.** `make check-zk-op-version` exists for the
Zookeeper Operator;
there is no equivalent for Solr, so a partial bump passes CI. The skill
should say so, and a
follow-up could add `hack/solr-version/check-version.sh` modelled on
`hack/zk-operator/check-version.sh`.
### The half that actually needs judgement
Deciding whether the release needs operator work: new config knobs, new CRD
fields, changed startup
or admin-API behaviour, changed defaults. The skill should give a concrete
triage — read the Solr
release notes for the span crossed, check whether anything the operator
calls has moved (the admin
API paths in `controllers/util/solr_api/`, the startup probes, the
security.json handling), and run
`make e2e-tests` against the new image, since **the e2e workflow is
permanently disabled in CI** and
is therefore not evidence of anything.
### The matrix that silently stops being true
`docs/modules/upgrade-notes/pages/upgrade-notes.adoc` carries a
hand-maintained Solr compatibility
matrix, currently columns `7.7` / `8.0`-`8.10` / `8.11` / `9.0`-`9.3` /
`9.4`+ with a row per
operator version through `v0.10.x`. Nothing regenerates or verifies it.
Adding a row, or widening a
column, is part of adopting a release and is the step most likely to be
skipped.
### Out of scope
Raising the *minimum* supported Solr version. Like the minimum Kubernetes
version, that is a support
promise rather than a dependency, and belongs in its own PR timed to a
release.
---
🤖 Issue text authored with AI assistance, approved by me
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
