File: release_guide.md

package info (click to toggle)
moarvm 2024.09%2Bdfsg-5
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 43,548 kB
  • sloc: cpp: 378,682; ansic: 293,618; perl: 8,274; java: 2,682; python: 1,296; makefile: 816; sh: 292
file content (116 lines) | stat: -rw-r--r-- 4,916 bytes parent folder | download | duplicates (2)
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.