| The Release Notes Application is entirely wiki content: creating a release note or a change means knowing its internal data model. A page has to be named after a short version (a change stored against 18.0-milestone-1 lives under a page called 18.0M1), a change page has to carry two objects (EntryClass plus ChangeClass – forget the first one and the change is invisible to every query), and change pages have to be numbered Entry001, Entry002, ... without two authors picking the same number. Today that knowledge is duplicated in Velocity in several wiki pages, and it is not available at all to anything outside the wiki (a script, a CI job, an agent creating release notes automatically). Add a Java API, in a new application-releasenotes-api module, that owns those rules:
- ReleaseNoteManager – create a release note from a product/version/date/released/template, derive its page name, and look notes up.
- ChangeManager – allocate the next Entry### name and create a change with both of its objects, in a single save.
- ReleaseNotesConfiguration – the instance-level default product and template.
- a releasenotes script service, so wiki pages call the API instead of reimplementing it.
Creation stays template-driven, so a wiki admin customising the release note or change template keeps getting their template through the API, and each creation is a single atomic save so no half-created entry can be left behind. Edit right is required on the target page, checked for both the user and the script author. The two creation paths in the application (Code.HomeReleaseNotes and the "Add ... Change" buttons) are refactored onto the API. The application behaves identically afterwards, with one wanted change: creating a release note with no product and no configured default now fails, instead of silently creating a bogus page. |
