Skip to content

Releases: version strings, tagging and building

Joseph Wright edited this page Nov 21, 2019 · 10 revisions

Version strings

As each part of the core LaTeX2e set up contains multiple files with independent version numbers, the bundles themselves are given overall version strings rather than expecting each source to report the same version number.

The kernel itself (latex2e/base)

Each major kernel release has a nominal date given in ISO format, e.g. 2020-02-02. This is not necessarily the date the release is finalised, but will typically be close to it. In general, we prefer to pick the 1st-of-month unless there is good reason (for example if we are going to release right in the middle of a month).

Patch levels (hotfixes to kernel major releases) retain the same nominal date and are marked as patch level, starting a 1 and incrementing. ('Patch level 0' is the initial major release of a cycle.)

Required bundles (latex2/required/...)

Each release of a bundle (amsmath, cyrillic, graphics, tools) is given a version string equal to the release date expressed in ISO format, e.g. 2020-02-02. Patch levels are not used unless there is a direct link to a kernel patch at the same time.

Tagging the sources

To update the sources (in particular the README.md files), run

l3build tag <string>

in the appropriate directory.

For the kernel itself, patch levels are given as a :<number> addition to the ISO date, for example

l3build tag 2020-02-02:1

for patch level one.

When on branches other than master, the same format is used to indicate a pre-release level, thus for example

git checkout develop &&
l3build tag 2020-02-02:3

would tag as pre-release 3 for kernel 2020-02-02.

Building releases

Building releases is set up automatically using the Travis-CI system. This is triggered by creating a tag and pushing to GitHub. Git tags start with an identifier then the (nominal) ISO. Thus to create a release of the kernel, on the master branch one would use

git tag -a -m "" release-<ISO>

The identifiers are

  • release A kernel release, which may include the required components
  • dev A pre-release: used only on the develop branch
  • amsmath
  • graphics
  • tools

When tagging patch levels or pre-releases, we use -PL<n> or -PR<n> after the ISO date, for example dev-2020-02-01-PR1 would be the first pre-release of the kernel for an upcoming 2020-02-01 nominal release date.

After pushing the tag to GitHub, Travis-CI will build zip files and send these back to be available as a new release or a pre-release: the latter happens for tags starting dev-.

Clone this wiki locally