blob: 262ca08d26c4968f71db401bcb5b2f7ce0b03eeb [file] [log] [blame]
The release criteria for libdrm is essentially "if you need a release,
make one". There is no designated release engineer or maintainer.
Anybody is free to make a release if there's a certain feature or bug
fix they need in a released version of libdrm.
When new ioctl definitions are merged into drm-next, we will add
support to libdrm, at which point we typically create a new release.
However, this is up to whoever is driving the feature in question.
Follow these steps to release a new version of libdrm:
1) Bump the version number in We seem to have settled
for 2.4.x as the versioning scheme for libdrm, so just bump the
micro version.
2) Run autoconf and then re-run ./configure so the build system
picks up the new version number.
3) Verify that the code passes "make distcheck". Running "make
distcheck" should result in no warnings or errors and end with a
message of the form:
libdrm-X.Y.Z archives ready for distribution:
Make sure that the version number reported by distcheck and in
the tarball names matches the number you bumped to in
4) Push the updated master branch with the bumped version number:
git push origin master
assuming the remote for the upstream libdrm repo is called origin.
5) Use the script from the xorg/util/modular repo to
upload the tarballs to the download area and
create an announce email template. The script takes one argument:
the path to the libdrm checkout. So, if a checkout of modular is
at the same level than the libdrm repo:
./modular/ libdrm
This copies the two tarballs to and creates
libdrm-2.4.16.announce which has a detailed summary of the
changes, links to the tarballs, MD5 and SHA1 sums and pre-filled
out email headers. Fill out the blank between the email headers
and the list of changes with a brief message of what changed or
what prompted this release. Send out the email and you're done!