|author||Joe Rayhawk <firstname.lastname@example.org>||2013-07-08 07:19:52 +0000|
|committer||Joe Rayhawk <email@example.com>||2013-07-08 07:19:52 +0000|
moin2mdwn: convert page Development/Documentation/ReleaseHOWTO
Diffstat (limited to 'Development/Documentation/ReleaseHOWTO.mdwn')
1 files changed, 54 insertions, 0 deletions
diff --git a/Development/Documentation/ReleaseHOWTO.mdwn b/Development/Documentation/ReleaseHOWTO.mdwn
new file mode 100644
@@ -0,0 +1,54 @@
+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|XorgReleases]].
+## Packages needed for releases
+Make sure you have up-to-date **released** versions of these packages before making module or katamari releases.
+* lib/libxtrans (when building modules such as libX11 or xserver that rely on it)
+## Making module 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_.
+* Pick a suitable version number, according to the [[X.org version number scheme|Development/Documentation/VersionNumberScheme]].
+* Apply that version number to configure.ac.
+* For the xserver module, update RELEASE_DATE variable as well.
+* Commit and push your _version bump_ to the remote repository.
+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.
+[[!format txt """
+util/modular$ ./release.sh --help
+Usage: release.sh [options] path...
+Where "path" is a relative path to a git module, including '.'.
+* For a single module this would typically be `../../util/modular/release.sh .`.
+* For multiple modules, this could be `util/modular/release.sh app/xfs app/xdm`.
+* The tarballs are created by _make dist_ or _make distcheck_.
+* The tag name is computed by the script as it is different for each module.
+* The tarballs are uploaded to the X.Org web site in the appropriate section.
+* The annotated tag is pushed to the remote repository.
+* The announce e-mail template with check-sum is created.
+Consult the help text for the available options. Consider running with `--dry-run` first.
+## Making katamaris
+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.
+* on annarchy:
+ * create /srv/xorg.freedesktop.org/archive/X11R7.x/src
+ * $EDITOR ~/util/modular/module-list.txt to update the list of modules for this release
+ * cd /srv/xorg.freedesktop.org/archive/X11R7.x/src
+ * ~/util/modular/roll-it-up.sh < ~/util/modular/module-list.txt
+ * cp [[../X11R7|Development/Documentation/X11R7]].3/index.html [[../X11R7|Development/Documentation/X11R7]].3/logo.png .
+ * $EDITOR index.html
+ * mkdir doc
+ * $EDITOR doc/RELNOTES.txt
+* update [[http://wiki.x.org/wiki/Releases/7.x|http://wiki.x.org/wiki/Releases/7.x]]
+* update [[http://wiki.x.org/wiki/|http://wiki.x.org/wiki/]] to point to the new release
+* send mail to the list \ No newline at end of file