1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
|
# MoarVM Release Guide
## Versions
MoarVM currently has a monthly release cycle, with releases made in time for
the month's NQP and Rakudo release. Version numbers are simply YYYY.MM. For
example, the January 2014 release is 2014.01. If any bugfix releases need to
be made, they should be numbered as 2041.01.1, 2041.01.2, etc.
## Making a release
1. Make sure that you are on the MoarVM commit you want to make a release
from, and that your status is clean.
2. Ensure that NQP and Rakudo will build and that `make test` in each is
clean. Also run `make spectest` in Rakudo; discuss any failures you see
with the Rakudo developers.
3. If possible, run NQP and Rakudo `make test` and Rakudo `make spectest` when
`#define MVM_DEBUG_NFG 1` and `#define MVM_DEBUG_NFG_STRICT 1` in src/strings/ops.h
after recompiling to make sure there have been no normalization bugs
introduced.
4. Do a checkout to a new branch with some name, preferred branch name equals to
the release version (e.g. `git checkout -b 2021.10`, substituting the correct version).
5. Update the `docs/ChangeLog` file with any significant changes since the previous release.
To do so, write down commits from the previous release merge commit to latest ones (using
Github interface or git's CLI). Changes are split into categories, usually to konw
a category where to place some change you can see what files were changes (e.g. changes
to JIT to to the JIT category or GC fixes go into GC category).
Do not forget to check merge commits, as they can bring in commits older than the previous
release merge commit and those won't be visible in the history.
6. Update the VERSION file with the release name.
7. Run `make release VERSION=2021.10`, substituting the correct version.
8. Take the `MoarVM-2021.10.tar.gz` file generated by step 7, copy it to a separate directory,
extract it, and then in that directory do:
perl Configure.pl --prefix=install
make install
install/bin/moar --version
8. Provided step 7 and 8 work, you have a release! Your git instance must
sign commits. Now we tag the release. The `-a` option adds a tag while
the `-s` makes sure the tag is signed. Even if your commits are signed by default,
you will need the -s option as well.
Note: For the tag's message, in the past we have used format:
'20XX.YY release'. To see the past release messages use `git tag -n9`
git tag -as 2021.10
9. Run `git verify-tag 2021.10` to make sure the signature is valid and the tag
was actually signed.
10. Run `git push origin refs/heads/2021.10:refs/heads/2021.100` assuming
the upstream remote is `origin` to push the branch and `git push origin --tags`
to push the tag. Open a Pull Request for the branch.
11. From here on this assumes you have the https://github.com/MoarVM/moarvm.org/ repository
in the same folder as the main MoarVM repo.
12. Make sure you have the Text::Markdown Perl 5 module and run:
./tools/moarvm.org_releases.pl > ../moarvm.org/releases.html
It should output to STDERR all the versions it found in ChangeLog make sure
the most recent release appears first and all releases going back to 2014.01
appear.
13. Manually edit the `moarvm.org/index.html` file to have the DL link and mention the most
recent release.
Changes need to be made on lines:
- 36: Large text
- 38: Description text
- 41: Download link
14. Create a gpg signature
gpg --detach-sign --armor MoarVM-2021.10.tar.gz
Verify the signature:
gpg --verify MoarVM-2021.10.tar.gz.asc
15. Copy the tar.gz and the signature:
cp MoarVM-2021.10.tar.gz MoarVM-2021.10.tar.gz.asc ../moarvm.org/releases
16. Commit release to moarvm.org repo and check moarvm.org after 5-10 minutes and
make sure download works.
cd ../moarvm.org
git add . # Add release files and changes to index.html and releases.html
git commit -m "Commit release 2018.08"
17. Make sure both pages look alright, open `index.html` and `releases.html` with
your browser and check markup highlighting.
18. If both look good, push with `git push origin master`
19. Merge the release Pull Request.
20. Create a MoarVM Github release using the script https://github.com/rakudo/rakudo/blob/master/tools/releasable/github-release.p6
raku github-release.p6 --repo=MoarVM/MoarVM --tag=2021.10 --token=... --asset=MoarVM-2021.10.tar.gz --asset=MoarVM-2021.10.tar.gz.asc
FIXME: currently the release script does not upload assets properly due to a 400 Bad Request returned,
so assets are added manually. It's a nice idea to investigate what has changed in the Github API
and fix it to avoid an extra step of manual work.
21. Update MoarVM article on Wikipedia with the latest release https://en.wikipedia.org/wiki/MoarVM
22. Time to prepare a Rakudo release.
|