Mercurial > hg > Members > anatofuz > MoarVM
comparison docs/release_guide.md @ 0:2cf249471370
convert mercurial for git
| author | Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp> |
|---|---|
| date | Tue, 08 May 2018 16:09:12 +0900 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:2cf249471370 |
|---|---|
| 1 # MoarVM Release Guide | |
| 2 | |
| 3 ## Versions | |
| 4 | |
| 5 MoarVM currently has a monthly release cycle, with releases made in time for | |
| 6 the month's NQP and Rakudo release. Version numbers are simply YYYY.MM. For | |
| 7 example, the January 2014 release is 2014.01. If any bugfix releases need to | |
| 8 be made, they should be numbered as 2041.01.1, 2041.01.2, etc. | |
| 9 | |
| 10 ## Making a release | |
| 11 | |
| 12 1. Make sure that you are on the MoarVM commit you want to make a release | |
| 13 from, and that your status is clean. | |
| 14 | |
| 15 2. Ensure that NQP and Rakudo will build and that `make test` in each is | |
| 16 clean. Also run `make spectest` in Rakudo; discuss any failures you see | |
| 17 with the Rakudo developers. | |
| 18 | |
| 19 3. If possible, run NQP and Rakudo `make test` and Rakudo `make spectest` when | |
| 20 `#define MVM_DEBUG_NFG 1` and `#define MVM_DEBUG_NFG_STRICT 1` in src/strings/ops.h | |
| 21 after recompiling to make sure there have been no normalization bugs | |
| 22 introduced. | |
| 23 | |
| 24 4. Update docs/ChangeLog with any significant changes since the previous release. | |
| 25 | |
| 26 5. Update the VERSION file with the release name. | |
| 27 | |
| 28 6. Run `make release VERSION=2017.10`, substituting the correct version name. | |
| 29 | |
| 30 7. Take the MoarVM-2017.10.tar.gz file generated by step 6, copy it to a separate directory, | |
| 31 extract it, and then in that directory do: | |
| 32 | |
| 33 perl Configure.pl --prefix=install | |
| 34 make install | |
| 35 install/bin/moar --version | |
| 36 | |
| 37 8. Provided step 5 and 6 work, you have a release! You need to setup git to be | |
| 38 able to sign your commits. The -a option adds a tag while the -s makes sure | |
| 39 the tag is signed. Even if your commits are signed by default, you will need | |
| 40 the -s option as well. | |
| 41 | |
| 42 git tag -as 2017.10 | |
| 43 | |
| 44 9. Run `git verify-tag 2017.10` to make sure the signature is valid and the tag | |
| 45 was actually signed. | |
| 46 | |
| 47 10. Upload it by committing the tar file | |
| 48 to https://github.com/MoarVM/moarvm.org/ in the releases directory. | |
| 49 | |
| 50 11. Make sure you have the Text::Markdown Perl 5 module and run: | |
| 51 | |
| 52 ./tools/moarvm.org_releases.pl > ../moarvm.org/releases.html | |
| 53 | |
| 54 It should output to STDERR all the versions it found in ChangeLog make sure | |
| 55 the most recent release appears first and all releases going back to 2014.01 | |
| 56 appear. | |
| 57 | |
| 58 12. Manually edit moarvm.org/index.html to have the DL link and mention the most | |
| 59 recent release. | |
| 60 Changes need to be made on lines: | |
| 61 - 36: Large text | |
| 62 - 38: Description text | |
| 63 - 41: Download link | |
| 64 | |
| 65 13. Create a gpg signature | |
| 66 | |
| 67 gpg --detach-sign --armor MoarVM-2018.04.tar.gz | |
| 68 | |
| 69 Verify the signature: | |
| 70 gpg --verify MoarVM-2018.04.tar.gz.asc | |
| 71 | |
| 72 14. Copy the tar.gz and the signature: | |
| 73 | |
| 74 cp MoarVM-2018.04.tar.gz MoarVM-2018.04.tar.gz.asc ../moarvm.org/releases | |
| 75 | |
| 76 15. Optionally, update the ports/macports/Portfile to reflect this latest | |
| 77 version, and open a ticket at https://trac.macports.org/newticket to get | |
| 78 the macport updated. (For now, just make Coke do it.) | |
| 79 | |
| 80 16. Do something fun to celebrate. Like watching nyan cat, or having a beer. Or | |
| 81 why not both? |