Reading an Xi Version Number and Distribution File Name

Version Number Format

Each product carries two version numbers, and they answer different questions. Confusing them is the most common source of trouble when reading a version string.

Release version (for example 1.9.1)

The MAJOR.MINOR.PATCH number that names the released software. This is what the package and the distribution file are called, and it is what you quote when you report a problem.

Format version (for example 6.451)

The generation of the on-disk data files and of the network record format. Its first component is the part that matters - Xi-Batch is format 6, Xi-Text is format 23. It moves only when Xi Software deliberately changes a stored or transmitted format, which is far rarer than a release.

The two numbers are independent, and the two products do not share either of them. At the time of writing Xi-Batch is release 1.9.x on format 6, and Xi-Text is release 1.25.x on format 23. An Xi-Text release number is therefore not comparable with an Xi-Batch one.

A release version may carry two further parts when it appears in a file name:

MAJOR.MINOR.PATCH[~pre]+[REVISION.]BUILDREF

MAJOR version

Significant changes, possibly breaking compatibility

MINOR version

New features, backwards compatible

PATCH version

Bug fixes, no new features

~pre marker

Present on an iterative pre-release build. A finished release does not carry it.

REVISION

A counter that increases when the same software is packaged again with no change to the programs themselves.

BUILDREF

A reference identifying the individual build run. See "Build Reference Interpretation" below.

Product Naming

Two forms of the product name are in circulation, and both refer to the same software:

xibatch_legacy or xibatch

Xi-Batch

xitext_legacy or xitext

Xi-Text

xiutil_legacy or xiutil

Xi-Util utility programs, which are distributed separately from the two main products

The legacy designation names the supported production line, which is the line every customer runs and the line all maintenance releases are cut from. It does not mean the software is unsupported. Older distribution files carry the longer form; newer ones may carry the shorter. If you are unsure which product a file belongs to, the name always begins with xibatch, xitext or xiutil.

A product that ships a graphical front end distributes it as a separate file whose product field carries a component suffix, for example xitext_legacy+gtk3 or xitext_legacy+motif. These are additions to the main package, not alternatives to it.

Distribution File Naming

Packages - the .deb and .rpm files - are named product first:

PRODUCT-BLEND-VERSION-CPU-MAKE-OSNAME.deb

Example Xi-Text:

xitext_legacy-standard-1.25.2+1.1782476231-x86_64-linux-rockylinux9.rpm

Example Xi-Batch:

xibatch_legacy-standard-1.9.0+1.1782482597-x86_64-linux-debian13.deb

The release tarball is still named platform first, which is the older order:

CPU-MAKE-OSNAME-PRODUCT-BLEND-VERSION.tar.gz

Example:

x86_64-linux-rockylinux9-xitext_legacy-standard-1.25.2+1782476231.tar.gz

The two orders carry the same fields and the same values; only the order differs. Xi Software is bringing the tarball onto the package order, so both may be seen on a download list.

Naming Components

Product (xitext_legacy)

Which Xi Software product, optionally with a + component suffix for a graphical front end

Blend (standard)

Build variant - "standard", or a named blend. See "Identifying Custom Builds" below.

Version (1.25.2+1.1782476231)

Release version with its optional pre-release marker, revision and build reference

CPU architecture (x86_64)

Processor type, as the machine's own uname reports it - for example x86_64, aarch64, sparcv9, ia64, hppa. A documentation-only or otherwise architecture-independent file uses noarch.

Make (linux)

Kernel or operating-system family - linux, solaris, aix, hpux. This is what distinguishes a Linux build from a Solaris build on the same processor.

OS name (rockylinux9)

Distribution and its major release only - rockylinux9, debian13, sles15. It does not carry a minor release, so a file for Rocky Linux 9 is named rockylinux9 whatever the point release.

No field ever contains a hyphen, so a file name can be split on hyphens without ambiguity.

Extract Folder Format

The release tarball extracts to a directory named:

PRODUCT-BLEND-VERSION

The build reference is excluded from the directory name.

Examples:

• xibatch_legacy-standard-1.9.0/
• xitext_legacy-standard-1.25.2/

Why Versioning Changed

Platform diversity

Linux distributions vary in libraries and system configurations, so the distribution and its major release have to be part of the file name

Build traceability

The build reference identifies the individual build run, so a specific file can be traced back to its build record

Automated builds

Standardised naming enables automated build and test processes

Industry alignment

Follows established versioning standards for the release number

Customer clarity

Clear identification of product, platform, and variant

Checking Installed Version

There are two things to check, and a support call will usually ask for both.

The release version, from the package manager. On a packaged installation this is the quickest answer:

rpm -qa | grep -E 'xibatch|xitext'

or, on a Debian or Ubuntu system:

dpkg -l | grep -E 'xibatch|xitext'

Search rather than query a fixed name: the installed package name varies between the two formats and between releases, and on an RPM installation it also carries the blend, so a name such as xibatch_standard or xitext_legacy_cronus is what you will see.

The version compiled into the programs. This works on any installation, packaged or from a tarball, and is the authoritative answer because it comes from the binary itself. Each program carries an identification string, which you can read out with:

strings /usr/libexec/xi/btsched | grep '@(#)'

for Xi-Batch, or:

strings /usr/libexec/xi/spshed | grep '@(#)'

for Xi-Text. On Solaris, AIX and HP-UX the what command does the same job:

what /usr/libexec/xi/spshed

The line you are looking for reads, for example:

@(#) $Id: Xi-Text 1.25.2 (format 23.500) SHM FLOCK UDS $

Reading it left to right: the product, its release version, its format version in brackets, and then the shared-memory, locking and inter-process communication mechanisms the build uses. A second line reports the operating system of the machine the build was made on.

Older builds omit the release version and show only the format version, as $Id: Xi-Text 23.500 SHM FLOCK UDS $. If that is what you see, take the release version from the package manager or from the name of the file the software was installed from.

Two cautions. No Xi-Batch or Xi-Text command has a version option, so there is nothing to run that prints the version directly. And if your installation places the programs somewhere other than /usr/libexec/xi - some blends do - use the location given by the SPROGDIR setting in the master configuration file under /etc/xi.

Version Compatibility

Compatibility is governed by the format version, not by the release version.

Same format version

The saved data files and the network record format are interchangeable. Any two releases sharing a format version can read each other's files and can talk to each other across a network. Every Xi-Batch release in current support is format 6, and every Xi-Text release is format 23.

Different format version

The saved data does not carry across, and hosts on a network disagree. The stored user file is named after the format version - btufile6 for Xi-Batch, spufile23 for Xi-Text - so a format change leaves the old file behind rather than corrupting it, and the product starts with an empty one. A change of format version is a migration, announced as such by Xi Software.

Because the format version is stamped into the file, a mismatch is detected and reported: the product warns that the user control file's version number differs from the software's, and attributes it to a mixture of binaries from different versions. Treat that message as a sign that programs from two installations have become mixed on one machine.

Upgrading within a format version

Stop the product, install the new package or tarball, start it again. The saved jobs, printers, variables and users are read straight back. The licence is unaffected, because it is tied to the machine rather than to the version.

Across a network

What must agree between two hosts is the format version. Two hosts running different release versions of the same product, on the same format version, interoperate.

On one host

Every Xi program on a machine should come from the same installation. Mixing programs from two releases is what produces the mismatch warning above.

Identifying Custom Builds

A blend is a variant of the same released software, built and packaged to suit a particular site or purpose. It is not a different version of the product: the release version and the format version are the same, and the programs behave the same way.

standard

The general-purpose build. This is what a customer receives unless something else has been arranged.

A named blend

A build arranged for a specific site or environment, for example cronus, vmware or a composite such as cronus+vmware. There is also a debug blend, used when Xi Software support needs extra diagnostic output.

The blend appears as its own field in the file name:

xibatch_legacy-cronus+vmware-1.9.0+1.1782482597-x86_64-linux-rockylinux9.rpm

What you observe on an installed system is that a non-standard blend puts its programs, help files and spool directories in different places from the standard build. If the paths in this knowledgebase do not match your system, a blend is the most likely reason; the master configuration file under /etc/xi records where the programs actually are.

Contact Xi Software support to confirm which blend an installation is running, or to discuss whether one is required.

Build Reference Interpretation

The build reference following the + - for example +1782476231 - identifies the individual build run. It is a timestamp taken when the build started, so it is unique to that build and always increases. Older files carry the same value in hexadecimal, for example +687a1f3c, which is why some build references look like a string of letters and digits.

It is not a source-code identifier, and two builds of the same software always have different build references.

Its uses are:

Unique naming

Every file Xi Software publishes has a distinct name, even when the release version is unchanged

Support diagnosis

Quoting it lets Xi Software support identify precisely which build you have

Ordering

A higher build reference is a later build of the same release version

Multiple Builds of Same Version

The release version names the software. Several builds of the same software have different build references:

• 1.25.2+1782476231 - built for one platform
• 1.25.2+1782478900 - built for another, or rebuilt later

Both carry the same software, release 1.25.2, and were built at different times or for different targets. The same is true of a re-packaged release, where the revision moves - 1.25.2+1 to 1.25.2+2 - while the programs are unchanged.

Where it matters whether the programs themselves actually differ, ask Xi Software support: each build has a record listing the content of every program it contains, and that record, rather than the file name, is the authority.