Versioning

When Versioning is on, Innesta proposes the version number for a release or a hotfix instead of asking you to remember it.

It is on by default wherever GitFlow is configured, and it can be switched off: tags are still created and the collision checks still run, but the suggestions, the prefix handling and the manifest integration stop.

What it suggests

• A release increments the minor component and resets the patch: 1.4.3 becomes 1.5.0.
• A hotfix increments the patch: 1.4.3 becomes 1.4.4.

The base is the newest matching semantic tag — local, or verified on the remote — and, when manifest integration is on, the version read out of your project’s manifest. Versions already taken by an existing release or hotfix branch or tag are skipped.

The prefix

Most repositories tag v1.5.0; some tag 1.5.0. Innesta distinguishes three states, and the middle one is the one that usually gets lost:

• No prefix configured — infer it from the newest matching tag.
• A prefix configured, such as v — use it.
• An empty prefix configured — a deliberate “no prefix”, which turns inference off.

An empty setting and an absent setting mean different things here, and Innesta keeps them apart rather than treating empty as unset.

Checking the remote

Before suggesting a version, Innesta can check the remote for tags and for release and hotfix branches. That check is a ten-second git ls-remote --refs, limited to the refs it needs. It never fetches and never creates a local ref, and it does not run when you open or refresh a repository — only when you are about to need the answer.

The remote it checks is the Git push destination, resolved the way Git resolves it: branch.<current>.pushRemote, then remote.pushDefault, then the branch’s own remote, then origin, then the only configured remote.

If there is no remote, the answer is local-only and says so. If the remote is ambiguous or unreachable, the answer is unverified and says that instead — and the operation can still go ahead on local data. The suggestion shows you which of the three you are looking at.

You see the local suggestion immediately, and it is refined when the remote answers — but not over text you have edited yourself. A number you typed is not overwritten by a check that finished afterwards.

The manifest

Innesta can read and update a version in your project’s own file. It looks for one it recognises — package.json, Cargo.toml, pyproject.toml, then Info.plist — or uses a path and a pattern you configure, which is checked first when you have set one.

The pair is only accepted if it works: the path has to stay inside the repository, and at least one GitFlow base branch has to expose a readable semantic version through it. Release and hotfix are reported separately, since release reads from integration and hotfix from production and one can work while the other does not.

Where the version is unambiguous, the pattern can be derived; where a file contains several things that look like versions, you have to say which. A setting written outside Innesta that is unsafe or unusable is ignored in favour of a built-in file, and reported rather than silently substituted.