Reading an Xi Version Number and Distribution File Name

Both productsXi-BatchXi-Textdownloadspackagingversioning

An Xi version string carries two different numbers, and a distribution file name carries several fields. This article says what each one means, and how to read the version of an installation in front of you.

Two version numbers, answering different questions

Each product carries two version numbers.

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 "The build reference" below.

The two forms of the product name

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: the line every customer runs, and the line all maintenance releases are cut from. Older distribution files carry the longer form; newer ones may carry the shorter. 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 installed alongside the main package.

How a distribution file is named

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

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

In the examples that follow the blend field is written as \, standing for the build variant your own file carries. See "Blends" below.

Example Xi-Text:

xitext_legacy-<variant>-1.25.2+1.1782476231-x86_64-linux-rockylinux9.rpm

Example Xi-Batch:

xibatch_legacy-<variant>-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-<variant>-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.

The fields in the name

Product (xitext_legacy)
Which Xi Software product, optionally with a + component suffix for a graphical front end

Blend (\)
Build variant. See "Blends" 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.

What the tarball extracts to

The release tarball extracts to a directory named:

PRODUCT-BLEND-VERSION

The build reference is excluded from the directory name.

Examples:

• xibatch_legacy-\-1.9.0/
• xitext_legacy-\-1.25.2/

Finding the version of an installation

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_\ or xitext_legacy_\ 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, since it comes from the binary. Each program carries an identification string, 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.

No Xi-Batch or Xi-Text command has a version option, so there is nothing to run that prints the version directly. Where an 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.

What has to match between two installations

The format version governs compatibility.

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 in place 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.

Blends

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

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

A named blend
A build arranged for a particular site, or a diagnostic build issued by Xi Software support while a problem is being investigated.

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

xibatch_legacy-<variant>-1.9.0+1.1782482597-x86_64-linux-rockylinux9.rpm

What you observe on an installed system is that such a blend puts its programs, help files and spool directories in different places from the default 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 are.

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

The build reference

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.

Two builds of the same software always have different build references, so every file Xi Software publishes has a distinct name even when the release version is unchanged. Quoting the reference lets Xi Software support identify precisely which build you have, and a higher build reference is a later build of the same release version.

Several builds of one release

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 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.

Related articles

All articles · Release notes · Contact support