Repository navigation
Decide future-major compatibility policy without committing 1.x to breaking changes #142
Description
Reviewed 2026-09-25 (America/Los_Angeles) against main at bd249f5. Execution order and cross-issue ownership: #169. Batch 06.
This scope replaces the dated implementation prescriptions in the original report and earlier comments; linked historical evidence remains useful but must be rechecked before implementation.
Decision record, not implementation approval
Review Java baseline, explicit versus automatic module names, Jakarta tag package/split packages, eventual forUri removal, legacy adapter lifecycle, ESAPI dependency scope and whether a future Java baseline permits single-release JARs. Closed not-planned proposals remain closed unless separately reconsidered.
- Record keep/change/defer with rationale and migration cost for each item, using real consumer evidence; a small code-search result is not a census of downstream usage.
- Preserve Java 8 runtime, existing published API/module identities and dependency scopes throughout 1.x unless an independently reviewed policy explicitly changes that commitment.
- Keep Complete forUri deprecation across registry and tag APIs without removing 1.x support #130 deprecation compatible with 1.x and Align ESAPI URL-component semantics and define safe adapter context contracts #100's context contract decisions; do not convert optional design proposals into assumed removals.
- Announce any accepted future break with adequate migration notice before implementation; create focused implementation issues only for accepted decisions.
- Coordinate versioning/non-goals with Rewrite the README and context guide, incorporating #114 and current 1.5 contracts #128. New JSON/template support and existing compatibility tests must be reflected accurately.
This Batch 06 milestone is a decision queue, not a promised 2.0 release. The 1.5 release gate in RELEASING.md still requires an explicit disposition/evidence for every open item; merely moving one to this queue does not satisfy it.
Activity
[-]Record the 2.0 decisions: Java baseline, module names, tag package, forUri, adapters[/-][+]Decide future-major compatibility policy without committing 1.x to breaking changes[/+]Propagate the forUri deprecation to Encoders, tags and TLDs (#130)
jmanico commentedon Sep 26, 2026
Completed by #190's compatibility decision record.
Every item now has an explicit keep/defer decision, consumer evidence, rationale and migration cost: Java 8; explicit/automatic module identities; shared Jakarta tag packages; forUri retention through 1.x; javax/ESAPI adapter lifecycle and ESAPI compile scope; multi-release JARs; and exact-output/versioning policy. Existing fixtures are not presented as a downstream adoption census. JSON and ordinary untagged templates remain merged 1.5 features.
No future break is accepted for implementation. A focused decision, consumer impact evidence, published migration notice and appropriate notice period must precede implementation tickets or removals. Previously declined proposals stay closed. The README, context guide and contribution guide link the record.
Sol review followed by final Astra review found no actionable findings at
70720012ab25d5218ef16811fbd6ef2f29127c44; the 28 required PR checks passed before merge. This closes the decision work, not the full 1.5 release gate. #110/#111 retain their independent evidence/access work.