3. Release notes¶

This documentation corresponds to Border version 1.99.7.20250831123527.772ce56e35.

3.1. Border 1.99.7¶

This is the first release of Border. Border has been a part of a source code tree with other dependency components such as Loop and Lease for some time now. It was not packaged for release previously.

The following are release notes for Border 1.99.7:

RT1428: Border is now packaged.
RT1642: A header was added to Border web licenses.
RT1664: Border now supports the listen-on statement in border.conf(5).
RT1665: The border process now runs as a daemon.
RT1667: The border process now drops privileges when run as root user using capabilities under Linux. It also supports being run in a chroot directory.
RT1666: The border process now creates PID files in its runstate directory.
RT1668: The border process is now run as the border user when started from the systemd border.service.
RT1673: Copyright year was updated in various web source files.

To install Border, please see the chapter titled chap_installation.

3.2. Border version numbering scheme¶

Border version numbers have the grammar <MAJOR>.<MINOR>.<PATCH>.<COMMIT-TIMESTAMP>.<COMMIT-HASH>. The MAJOR and MINOR version numbers together represent a source code branch of Border (see Border branches).

The MAJOR version number is incremented when configuration options, API, and behavior of features change compared to the existing version. Switching to a new MAJOR version may require modifying existing config files to make them compatible with the new version.
The MINOR version number is incremented when new configuration options, API, and features are introduced that are compatible with existing configuration options. Switching to a new MINOR version will not require modifying existing config files to make them compatible with the new version.
The PATCH version number is incremented when only bugs have been fixed in a new version. Switching to a new PATCH version will not require modifying existing config files to make them compatible with the new version.
The COMMIT-TIMESTAMP field is auto-generated and contains the UTC timestamp of the source code commit from which the Border release was made. The timestamp value is formatted as YYYYMMDDHHMMSS, as the output of:
```
date +%Y%m%d%H%M%S
```
The COMMIT-HASH field is auto-generated and contains the abbreviated commit hash of the source code commit from which the Border release was made. The hash value is formatted as the output of:
```
git log -n1 --reverse --pretty=%h
```

For example,

If you're upgrading from version 1.2.1 to version 1.4.0, Border's config files should not require any changes. You may also check for new features that have become available in the 1.4 branch.
If you're upgrading from version 1.2.1 to version 2.0.0, it is possible that some of the contents of your existing config files may need changes. You may also check for new features that have become available in the 2.0 branch.
If you're upgrading from version 1.2.1 to version 1.2.4, Border's config files should not require any changes. The newer version only contains bugfixes.

Note

During a major version's release series, features and/or programs scheduled for removal in the next major release may be marked as deprecated. They will however still be supported until the end-of-life of that major release.

3.2.1. Stable and development versions¶

Even-numbered minor versions indicate stable branch releases, whereas odd-numbered minor versions indicate development banch releases. For example,

1.2.0 is a stable branch release,
1.3.0 is a development branch release,
1.99.0 is a development branch release,
2.0.3 is a stable branch release, and
2.1.1 is a development branch release.

Warning

Development branch releases should not be used in production as their features and interfaces may change. Development branch releases may not work properly, may have unexpected behaviors, may crash, etc.

3.3. Border branches¶

The following is information on current Border branches.

Branch	Type	First release date	End-of-life date
1.99	Development	To be announced	To be announced
2.0	Stable	To be announced	To be announced

Development branches have no planned end-of-life. Typically, development on such branches is stopped when a new MINOR+1 or MAJOR+1 stable branch is created off it.