release: cut 8.1.0.01, and fix client/server version-mismatch detection

[jcschaff]

What

Cuts 8.1.0.01, the first release candidate for VCell 8.1, moves the build number onto the 8.1.x sequence, and repairs the client/server version check — which has been unable to detect a PATCH-level mismatch since 2022.

Published numbers up to 8.0.28.01 are unchanged; nothing already released is renumbered.

The version check

A VCell patch release can carry a breaking API change. So a client and server differing in MAJOR, MINOR or PATCH are not known to be compatible, and the check now reports all three. Only BUILD is ignored.

That is what the check was written to do in 2018. It could not, because of the parser bug below: getPatchVersion() returned MINOR, so the comparison tested MINOR twice and ignored PATCH entirely. Across the whole 8.0 line every build parsed as (8, 0, 0), so the warning was effectively dormant.

Expect it to appear more often — a patch difference alone is now enough. It remains advisory and does not prevent use.

Mid-session server updates

The client reconnects on its own after a deployment. That path — the package-private ClientServerManager.reconnect() the Reconnector drives — went straight to connectToServer() and skipped the version check entirely, so a user could work on against a server their client no longer matched, with no sign anything had changed.

The automatic reconnect now runs the check, only once the reconnect has succeeded: a failed attempt says nothing about the server's version, and the check makes an HTTP call of its own that the retry loop must not repeat.

Same comparison either way; only the advice differs:

found	message
at login, or a user-initiated reconnect	download the current client
mid-session, after an automatic reconnect	save your work, exit and restart to install the matching version

The mid-session message does not tell the user their session is safe to continue. If a patch can break the API, that promise cannot be made.

The parser fix (#2011)

VCellSoftwareVersion read PATCH from parts[1] instead of parts[2], so getPatchVersion() returned a copy of getMinorVersion().

The line dates from 2018, when the same statement used split(".") — a regex matching any character, so the split returned an empty array and every part stayed -1. A 2022 one-line fix to that argument, inside an unrelated commit about compartment reordering, made MAJOR and MINOR work for the first time and made this typo live alongside them. Its only consumer compared it against an equally wrong value, so nothing surfaced for four years.

Verified against the recompiled class:

version string	major	minor	patch
Alpha_Version_8.0.28_build_01	8	0	28 ✓ (was 0)
Alpha_Version_8.1.0_build_01	8	1	0 ✓ (was 1)

Adds the class's first tests (3, @Tag("Fast")), including one distinguishing 8.1.0 from 8.0.1 — a pair the old parser could not tell apart.

Closes #2011.

Note on the dialog

It is not dismissible. VCell has a "Do not show this warning again" mechanism (UserPreferences + UserMessage) that this dialog does not use. Left alone deliberately — a separate decision, and more relevant now that the warning will be seen more often.

Verification

• mvn -o compile -pl vcell-apiclient -am — clean
• VCellSoftwareVersionTest — 3 tests, 0 failures
• CRLF preserved in all three Java files (checked byte-wise; no LF-only lines introduced)

Deploying to dev (alpha) after merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FUd61NUJgz88h4PZs5MqHn