Skip to main content

neqsim-version-bump-decision

Use when deciding whether a NeqSim project version request should be a patch or minor release. Classifies fixes, refactors, and additive features; checks Java serialization compatibility. Major-version decisions remain manual.

Source facts

Repository
equinor/neqsim
Last source activity
October 16, 2026 at 00:01
Detected SKILL.md language
English
Stars
156
Forks
73

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
neqsim-version-bump-decision
description
Use when deciding whether a NeqSim project version request should be a patch or minor release. Classifies fixes, refactors, and additive features; checks Java serialization compatibility. Major-version decisions remain manual.
# NeqSim Version Bump Decision ## Scope Use this skill for the NeqSim project's own release version, not dependency or Maven plugin versions. For dependency/plugin upgrades, use [`neqsim-maven-version-maintenance`](../neqsim-maven-version-maintenance/SKILL.md). This skill recommends patch or minor. It does not decide or apply a major version, create a GitHub release, or publish artifacts. ## Decision Rules | Change | Recommendation | Conditions | |---|---|---| | Bug fix, refactor, or performance correction | Patch | No public API/capability addition or incompatible API change; serialization gate below passes. | | New backward-compatible capability or public API | Minor | Existing APIs and serialized state remain compatible. | | Removed or incompatible public API, incompatible serialized state, or uncertain compatibility | Manual major review | Do not recommend or apply a patch/minor bump as a workaround. A human decides the major version. | Use SemVer increments from the current released version. For example, from `3.25.0`, a patch candidate is `3.25.1` and a minor candidate is `3.26.0`. Do not infer or choose a major version; that decision remains manual. A patch release does not satisfy the minor-or-major deprecation period in the [API lifecycle policy](../../../docs/development/api-lifecycle.md). ## Serialization Compatibility Gate Patch recommendations require evidence that serialized objects from supported previous releases remain readable and retain their intended state after loading. Apply this gate to every affected `Serializable` class and its serialized object graph: - Preserve an explicit `serialVersionUID`. If the class relies on a computed UID, compare it with the previous released version; do not assume a source-level refactor leaves it unchanged. - Check serialized field names, types, and meanings, plus any custom `readObject`, `writeObject`, `readResolve`, `writeReplace`, or `Externalizable` behavior. - A new serialized field is acceptable only when old streams load correctly, its default state is valid, and compatibility is verified. A renamed or retyped field, changed UID, or changed interpretation that prevents correct restoration fails the patch gate. - Prefer a fixture serialized by a supported released version and test loading it with the candidate code. A same-version round trip alone does not prove cross-version compatibility. Test candidate-to-old-reader compatibility too when that is part of the persistence contract. If there is no suitable prior-release fixture or other defensible compatibility evidence, report the gate as **unverified** and do not recommend patch. Request manual review; do not invent fixtures or claim compatibility from a matching UID alone. ## Procedure 1. Read the requested change and its diff. Identify the current released project version and confirm the core revision in `pom.xml`, `pomJava8.xml`, and `neqsim-mcp-server/pom.xml`. The MCP server's own artifact version is separate; do not change it as part of a NeqSim core version bump. 2. Classify the change by the decision table. A bug fix or refactor that also adds a new public capability is minor, not patch. 3. For a patch candidate, verify public API compatibility and complete the serialization compatibility gate. For a minor candidate, verify that existing APIs and previously serialized state remain usable. 4. If either compatibility check fails, or evidence is insufficient, stop at **manual review required**. Do not apply a patch or minor version to avoid confronting an incompatible change. 5. Report the recommendation, target version, change classification, API and serialization evidence, tests run, and unresolved risks. If the user asks to apply the recommended patch/minor version, update the coordinated project core revision in all three POMs and validate the core, Java 8, and MCP Maven configurations. Do not publish a release. ## Expected Result Return one of: - **PATCH** with the target patch version and passing compatibility evidence. - **MINOR** with the target minor version and a backward-compatible additive change summary. - **MANUAL MAJOR REVIEW** with the incompatible or unverified contract and why the skill cannot choose the major version.
View on GitHub