This page is about how to make a module release, for maintainers. If you are wondering about where to download the latest release of X.Org, please see XorgReleases.
Make sure you have up-to-date released versions of these packages before making module or katamari releases.
You must make a release if you have changed the ABI or API of your module and other modules rely on it. Likewise, the module to be released must not depend on unreleased code changes in any of its dependencies. Assuming the development and test (including make distcheck) have completed successfully and all commits have been pushed to the remote repository, the following steps will perform a version bump.
Repeat the above steps for each module you wish to release. The module source from the repository is now ready to be released, meaning the version bump commit is to be tagged, a set of tarballs is to be created and uploaded to the X.Org web site and an announce mail template is to be created which you can send to the xorg-announce mailing list.
The script util/modular/release.sh
will perform those steps for each module to be released. Invoke the release.sh
script from any parent directory where the git modules to be released can be reached.
util/modular$ ./release.sh --help
Usage: release.sh [options] path...
Where "path" is a relative path to a git module, including '.'.
../../util/modular/release.sh .
.util/modular/release.sh app/xfs app/xdm
.--dry-run
first.How to make badged semi-annual rollup releases, for release managers. This is basically what happened for 7.3, only that involved more flailing around.