Diff for "Development/Documentation/ReleaseHOWTO"

Differences between revisions 28 and 29
⇤ ← Revision 28 as of 2012-02-09 12:59:06 →
Size: 3384
Editor: modemcable045
Comment: RELEASE_DATE only applies to xserver
← Revision 29 as of 2012-04-29 21:02:30 → ⇥
Size: 3408
Editor: modemcable019
Comment: Updates following the release of a new release.sh script
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
You '''must''' make a release if you have changed the ABI or API of your module and other modules rely on it. 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''.
Line 20: Line 20:
 * Make sure all relevant changes have been committed to your local repository first with `git status`. Remember, this is git, so `git commit` only changes your local repository; you must then do `git push` to push your changes out to the world.
 * Verify your module builds with make distcheck. Verify that the built module actually works. It shouldn't have any dependencies on unreleased components (e.g. xf86-video-ati shouldn't be released if it depends on changes to xorg-server that are only in git master).
 * Push your version bump and other changes to the central repository with `git push`.
 * Tag your release, as foobar-1.2.3, for module foobar version 1.2.3. Note that the tag must have a message ('annotation').
   * `git tag -m "Xorg Server Version 1.0.99.2" xorg-server-1.0.99.2`
 You can obtain the message used for the previous tag by calling `git show xorg-server-1.0.99.2`.
 * Run the release script from util/modular/release, which will generate an email for you containing the MD5/SHA1 sums of the tarballs, the git log, et al, as well as copying it in place and pushing your tag.
   * i.e. in your module's directory: `<pathto>/util/modular/release.sh proto inputproto-1.4.1 inputproto-1.4.2`
   * Warning: if you're doing a branch release, the release script will also push what's unpushed on your master branch.
 * send the announce email generated, remembering to sign it. E.g. `mutt -H libXfont-1.4.2.announce`
 * Update other modules that depend on the change. For the xserver module, change the REQUIRED_MODULES line in configure.ac		  * Commit and push your ''version bump'' to the remote repository.
Line 32: Line 22:
There are no more modules remaining in CVS, but if you have to do something there, consult the ancient scrolls. 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.
Line 34: Line 24:
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 '.'.
}}}

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

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.

Packages needed for releases

Make sure you have up-to-date released versions of these packages before making module or katamari releases.

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.

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

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.