mirror of
https://gitlab.freedesktop.org/mesa/drm.git
synced 2025-12-20 04:40:09 +01:00
8f245b777b
It seems that the tests don't need DRM master anymore? at least make distcheck passes when X is running. release.sh is also invoked with just the path to the libdrm git checkout and we don't want to pass additional arguments that will be treated as additional modules we want to release. Also, make a note that release.sh will run make distcheck for you, so we don't strickly need to run it beforehand. Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
65 lines
2.7 KiB
Text
65 lines
2.7 KiB
Text
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) Ensure that there are no local, uncommitted/unpushed
|
|
modifications. You're probably in a good state if both "git diff
|
|
HEAD" and "git log master..origin/master" give no output.
|
|
|
|
3) Bump the version number in configure.ac. We seem to have settled
|
|
for 2.4.x as the versioning scheme for libdrm, so just bump the
|
|
micro version.
|
|
|
|
4) Run autoconf and then re-run ./configure so the build system
|
|
picks up the new version number.
|
|
|
|
5) (optional step, release.sh will make distcheck for you, but it can be
|
|
heart warming to verify that make distcheck passes)
|
|
|
|
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:
|
|
libdrm-X.Y.Z.tar.gz
|
|
libdrm-X.Y.Z.tar.bz2
|
|
=============================================
|
|
|
|
Make sure that the version number reported by distcheck and in
|
|
the tarball names matches the number you bumped to in configure.ac.
|
|
|
|
6) Commit the configure.ac change and make an annotated tag for that
|
|
commit with the version number of the release as the name and a
|
|
message of "libdrm X.Y.Z". For example, for the 2.4.16 release
|
|
the command is:
|
|
|
|
git tag -a 2.4.16 -m "libdrm 2.4.16"
|
|
|
|
7) Push the commit and tag by saying
|
|
|
|
git push --tags origin master
|
|
|
|
assuming the remote for the upstream libdrm repo is called origin.
|
|
|
|
6) Use the release.sh script from the xorg/util/modular repo to
|
|
upload the tarballs to the freedesktop.org download area and
|
|
create an annouce 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/release.sh libdrm
|
|
|
|
This copies the two tarballs to freedesktop.org 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!
|