A Version String Does Not Prove a VPN Plugin Feature

Three questions separate a version argument from a feature investigation: which component is supposed to provide the option, which version of that component is actually installed, and what its changelog says about it. A plugin's number on its own answers none of them. The tempting shortcut, comparing a shortened version to a tutorial's minimum, fails because distribution version strings are not decimals. Decide what you are comparing before you compare it.

The option may live in NetworkManager, in its VPN plugin, in the underlying engine, or in a separate desktop frontend. Those are four projects with four release histories.

Four Components, Four Release Histories

The editor you see is usually a plugin, and the plugin calls an engine such as the OpenVPN binary or a WireGuard implementation. NetworkManager itself supplies the connection model, and a desktop frontend may add its own fields on top. A feature can appear in any of them, and upgrading one does not upgrade the others. A newer engine is not evidence that the installed editor can import an option the engine supports.

Start from the symptom: is the field missing from the dialog, absent after import, or present but ignored? Those observations point at different components and need different evidence.

Parse the Version Before Comparing It

Debian's package policy defines the format as epoch, upstream version and packaging revision. The epoch is compared first, then the upstream portion, then the revision, using the package manager's own ordering rules rather than decimal arithmetic or a plain alphabetic sort. A tilde sorts before everything, including the end of that portion, which is how a release candidate precedes the final release. Reading the parts separately is what makes a comparison meaningful.

Do not invent a conversion rule for some other scheme in which 0.8.999 looks close to 0.9. Proximity of digits is not evidence about content.

Ask What Is Installed and What Would Be

apt-cache policy reports the installed version, the candidate and the repository each comes from, for every package you name. Read it for the engine and the plugin both, and record complete strings rather than shortened forms. Local metadata can be stale, and a candidate version does not prove that a running process has loaded that build. If a service has not been restarted since the upgrade, the file on disk and the behaviour you observe can disagree.

Then read the matching changelog. A packaging revision can carry patches without adopting a new upstream number, which is exactly the case where the version looks unchanged and the behaviour differs.

Prove the Option in the Owning Component

For an import problem, inspect the installed plugin's supported fields and the saved result rather than the dialog alone. A label, a native data field and an engine argument may be three representations of one setting, and success at importing a file says nothing about whether every directive survived. Name the feature precisely: accepting this directive while preserving its authentication meaning, for example.

If the supported build for that release lacks the integration, choose an approved update path or a different client. Mixing another release's repository, or applying an archived source patch to raise a visible number, trades a version argument for an unsupported system.

A useful report names the distribution, the full package versions, the active connection owner, the required option and the observed saved behaviour. That is a reproducible question.