RELEASING 1.8 KB

12345678910111213141516171819202122232425262728293031323334353637383940
  1. The release criteria for libdrm is essentially "if you need a release,
  2. make one". There is no designated release engineer or maintainer.
  3. Anybody is free to make a release if there's a certain feature or bug
  4. fix they need in a released version of libdrm.
  5. When new ioctl definitions are merged into drm-next, we will add
  6. support to libdrm, at which point we typically create a new release.
  7. However, this is up to whoever is driving the feature in question.
  8. Follow these steps to release a new version of libdrm:
  9. 1) Bump the version number in meson.build. We seem to have settled for
  10. 2.4.x as the versioning scheme for libdrm, so just bump the micro
  11. version.
  12. 2) Run `ninja -C builddir/ dist` to generate the tarballs.
  13. Make sure that the version number of the tarball name in
  14. builddir/meson-dist/ matches the number you bumped to. Move that
  15. tarball to the libdrm repo root for the release script to pick up.
  16. 3) Push the updated master branch with the bumped version number:
  17. git push origin master
  18. assuming the remote for the upstream libdrm repo is called origin.
  19. 4) Use the release.sh script from the xorg/util/modular repo to
  20. upload the tarballs to the freedesktop.org download area and
  21. create an announce email template. The script takes one argument:
  22. the path to the libdrm checkout. So, if a checkout of modular is
  23. at the same level than the libdrm repo:
  24. ./modular/release.sh libdrm
  25. This copies the two tarballs to freedesktop.org and creates
  26. libdrm-2.4.16.announce which has a detailed summary of the
  27. changes, links to the tarballs, MD5 and SHA1 sums and pre-filled
  28. out email headers. Fill out the blank between the email headers
  29. and the list of changes with a brief message of what changed or
  30. what prompted this release. Send out the email and you're done!