chore(release): 1.7.0

[voj-tech-j]

Cuts a release from what #12 merged. No code changes — the version bump and the changelog, exactly the files RELEASING.md step 2 names.

What's in 1.7.0

Scheduled emails became Lettr's own rather than the sending provider's (TPL-2621).

• getState() returns ScheduledEmailState, not String — the one source-breaking change, see below.
• listScheduled() is new — there was no way to ask what was queued.
• schedule() returns ScheduledEmail instead of CreateEmailResponse; cancelScheduled() returns the cancelled email instead of void.
• getScheduled / cancelScheduled take requestId, renamed from transmissionId.
• getTransmissionId() is @Nullable — it was @Nonnull, which is now false for every pending email.
• A legacy read no longer hands back a null state: Gson maps an unrecognised enum value to null, so state: "delivered" broke getState()'s own @Nonnull contract. Fixed with a TypeAdapter answering UNKNOWN.

Why 1.7.0 and not 2.0.0 — flagging this honestly

getState() changing from String to an enum is source-breaking, and this repo's RELEASING.md says:

While on 0.x, breaking changes may ship in minor versions. Once we cut 1.0.0, the full semver contract applies.

By that rule this is a major. We're shipping it as a minor anyway, deliberately, to stay in step with the rest of the SDK family — lettr-php 2.8.0, lettr-rust 1.7.0, lettr-node 1.7.0, lettr-python 1.7.0, lettr-go 1.6.0 all carry the same API change as a minor. The API had already changed underneath every one of them, so a caller on 1.6.0 is not working today regardless of the number.

Unlike Go — where a major would force the module path to /v2 and rewrite every import — Java has no structural penalty for a major here. This is purely a consistency call, and the changelog names the break at the top of the section so nobody meets it by surprise.

Migration is one line: e.getState() == ScheduledEmailState.SCHEDULED instead of "scheduled".equals(e.getState()).

Also in here

The compare links at the bottom of CHANGELOG.md were missing entries for 1.6.0, 1.3.0 and 1.2.0, and the file never had an [Unreleased] link at all. RELEASING.md step 1 asks for those to be kept current, so they are filled in — every section now has a matching link.

Verification

./gradlew build  → BUILD SUCCESSFUL
./gradlew test   → BUILD SUCCESSFUL

Also confirmed the bump propagates the way RELEASING.md promises — processResources expands gradle.properties into the resource HttpClient reads at runtime, so the User-Agent follows automatically with no Java constant to hand-edit:

build/resources/main/com/lettr/version.properties → version=1.7.0

The functional work was verified live against the production API through example-java before #12 merged: all four endpoints, including DELETE now answering 200 with a body where it used to be 204.

After merging

Per RELEASING.md step 5, this one is not a git tag — creating the GitHub Release is what creates the tag and triggers publish.yml:

• Releases → Draft a new release
• Choose a tag → v1.7.0 → Create new tag: v1.7.0 on publish
• Title v1.7.0, description = the ## [1.7.0] section from CHANGELOG.md
• Publish release

The workflow then runs ./gradlew publish and POSTs to the Central Portal to finalise. Maven Central indexes within ~15–30 minutes.

Worth remembering: Maven Central is immutable. A bad release cannot be overwritten — it needs a new version.

🤖 Generated with Claude Code