chore(release): prepare 0.2.0 (QQQ 4.1, Forge sync fix) #29

Merged

james.maes merged 3 commits from chore/release-0.2.0-20261106 into main 2026-11-06 15:32:35 +00:00

Conversation 0 Commits 3 Files Changed 7

+145 -18

3 Commits

Author	SHA1	Message	Date
james.maesandClaude Fable 5.1	b50515a8e8	build(pom): flatten the CI-friendly revision in published POMs ... The root pom keeps its version in the CI-friendly ${revision} property and the shared ci-workflows Maven workflow deploys with a plain mvn deploy, so the installed and deployed module POMs carried an unresolved <parent><version>${revision}</version> that a consuming build cannot resolve (the retired CircleCI orb path published resolved POMs, 68e85e6). Add flatten-maven-plugin 1.7.3 in resolveCiFriendliesOnly mode so the published POMs carry the literal version; ignore the generated .flattened-pom.xml. Verified with Maven 3.9.11: clean verify passes (29 tests), the installed qbit-geo-data-0.2.0.pom declares parent version 0.2.0, and a throwaway consumer resolves com.kingsrook.qbits:qbit-geo-data:0.2.0 through the full parent chain. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: James Maes <james@kof22.com>	2026-11-06 08:51:21 -06:00
james.maesandClaude Fable 5.1	401e7ca471	chore(release): prepare 0.2.0 ... Set the revision to 0.2.0: main already started the 0.2.0 line (6337bfe) because the QQQ dependency moved from 0.35.0 to 4.1.0-RC.21, a minor change, not a patch. Align GeoDataQBitProducer.VERSION and its test with the pom. Add the 0.2.0 changelog entry, move the already-shipped 0.1.0 bullets out of Unreleased, and correct the README coordinates (artifactId qbit-geo-data, version 0.2.0, Gitea registry, Java 21 / QQQ 4.1). No tag, release or publish: a push to main only verifies; the v0.2.0 tag publishes through the shared ci-workflows Maven workflow. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: James Maes <james@kof22.com>	2026-11-06 08:46:06 -06:00
james.maesandClaude Fable 5.1	2fd63e734b	fix(sync): resolve country and state foreign keys and fail on rejected rows ... Port the sync-step half of GG Forge's qualified geo-data-sync.patch (its entity/producer half landed in b5787bb). The 0.1.0 step matched states on countryAlpha2 + code and cities on countryAlpha2 + stateCode + name, columns that do not exist in the schema, so it reported success after persisting 250 countries and zero states or cities. Resolve the bundled source codes to the persisted countryId and stateProvinceId before matching; match cities on stateProvinceId, name, latitude and longitude at the schema's seven-decimal precision; compare numbers by BigDecimal value so a second run is a no-op; reactivate an inactive row whose source entry returns; and check insert/update results so a row the backend rejects fails the sync with a QException. Same change as the Forge pin 0.1.0-forge.6ac6a0366c34-sync1, with the inline java.math qualifications turned into imports and the class Javadoc updated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: James Maes <james@kof22.com>	2026-11-06 08:46:05 -06:00