| Kristian Høgsberg | be957cc | 2009-12-03 17:49:31 -0500 | [diff] [blame] | 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 | |
| 6 | When new ioctl definitions are merged into drm-next, we will add |
| 7 | support to libdrm, at which point we typically create a new release. |
| 8 | However, this is up to whoever is driving the feature in question. |
| 9 | |
| 10 | Follow these steps to release a new version of libdrm: |
| 11 | |
| 12 | 1) Ensure that there are no local, uncommitted/unpushed |
| 13 | modifications. You're probably in a good state if both "git diff |
| 14 | HEAD" and "git log master..origin/master" give no output. |
| 15 | |
| 16 | 3) Bump the version number in configure.ac. We seem to have settled |
| 17 | for 2.4.x as the versioning scheme for libdrm, so just bump the |
| 18 | micro version. |
| 19 | |
| 20 | 4) Run autoconf and then re-run ./configure so the build system |
| 21 | picks up the new version number. |
| 22 | |
| 23 | 5) Verify that the code passes "make distcheck". libdrm is tricky |
| 24 | to distcheck since the test suite will need to become drm master. |
| 25 | This means that you need to run it outside X, that is, in text |
| 26 | mode (KMS or no KMS doesn't matter). |
| 27 | |
| 28 | Running "make distcheck" should result in no warnings or errors |
| 29 | and end with a message of the form: |
| 30 | |
| 31 | ============================================= |
| 32 | libdrm-X.Y.Z archives ready for distribution: |
| 33 | libdrm-X.Y.Z.tar.gz |
| 34 | libdrm-X.Y.Z.tar.bz2 |
| 35 | ============================================= |
| 36 | |
| 37 | Make sure that the version number reported by distcheck and in |
| 38 | the tarball names matches the number you bumped to in configure.ac. |
| 39 | |
| 40 | 6) Commit the configure.ac change and make an annotated tag for that |
| 41 | commit with the version number of the release as the name and a |
| 42 | message of "libdrm X.Y.Z". For example, for the 2.4.16 release |
| 43 | the command is: |
| 44 | |
| 45 | git tag -a 2.4.16 -m "libdrm 2.4.16" |
| 46 | |
| 47 | 7) Push the commit and tag by saying |
| 48 | |
| 49 | git push --tags origin master |
| 50 | |
| 51 | assuming the remote for the upstream libdrm repo is called origin. |
| 52 | |
| 53 | 6) Use the release.sh script from the xorg/util/modular repo to |
| 54 | upload the tarballs to the freedesktop.org download area and |
| 55 | create an annouce email template. The script takes three |
| 56 | arguments: a "section", the previous tag and the new tag we just |
| 57 | created. For 2.4.16 again, the command is: |
| 58 | |
| 59 | ../modular/release.sh libdrm 2.4.15 2.4.16 |
| 60 | |
| 61 | This copies the two tarballs to freedesktop.org and creates |
| 62 | libdrm-2.4.16.announce which has a detailed summary of the |
| 63 | changes, links to the tarballs, MD5 and SHA1 sums and pre-filled |
| 64 | out email headers. Fill out the blank between the email headers |
| 65 | and the list of changes with a brief message of what changed or |
| 66 | what prompted this release. Send out the email and you're done! |