Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Newer
Older
100644 204 lines (137 sloc) 5.368 kB
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
1 =head1 release_guide.pod - guide to Rakudo releases
2
3 Rakudo's development release cycle is based on Parrot's release
4 cycle. Parrot releases the third Tuesday of each month; Rakudo
5 will generally issue its own development release two days after
6 the Parrot release.
7
8 Each development release is given a sequential number and a
9 code name based on an active Perl Mongers group. Rakudo's
10 February 2009 release is #14; prior releases were bundled as
11 part of monthly Parrot releases.
12
13 =head2 Development releases
14
15 2009-02-26 Rakudo #14 "Vienna"
f67507c @pmichaud Release date and name updates.
pmichaud authored
16 2009-03-20 Rakudo #15 "Oslo"
381d26e @pmichaud Updates to docs/announce and docs/release_guide.pod .
pmichaud authored
17 2009-04-23 Rakudo #16 "Bratislava"
c4fa3ba @pmichaud Update docs/release_guide.pod .
pmichaud authored
18 2009-05-21 Rakudo #17 "Stockholm"
7032827 @pmichaud Release #18 is no longer "planned" -- it "happened". masak++
pmichaud authored
19 2009-06-18 Rakudo #18 "Pittsburgh"
ee402a7 @pmichaud Fill in a release name for #19 (Chicago)
pmichaud authored
20 2009-07-23 Rakudo #19 "Chicago"
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
21
22 =head2 Planned 2009 releases
23
24 Dates are based on Parrot's expected release schedule.
25
26 2009-08-20 Rakudo #20
f67507c @pmichaud Release date and name updates.
pmichaud authored
27 2009-09-17 Rakudo #21
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
28 2009-10-22 Rakudo #22
29 2009-11-19 Rakudo #23
30 2009-12-17 Rakudo #24
31
381d26e @pmichaud Updates to docs/announce and docs/release_guide.pod .
pmichaud authored
32 =head2 Suggested .pm group names for future releases
33
bcdaaff @pmichaud Update release_guide.pod with more names.
pmichaud authored
34 PDX.pm
35 Atlanta.pm
381d26e @pmichaud Updates to docs/announce and docs/release_guide.pod .
pmichaud authored
36 BristolBath.pm
6d8bf89 @pmichaud Add another suggested .pm name for upcoming releases.
pmichaud authored
37 Milan.pm
381d26e @pmichaud Updates to docs/announce and docs/release_guide.pod .
pmichaud authored
38 Seoul.pm
39
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
40 =head2 Steps to create a release (for release managers)
41
42 Each Rakudo development release is timed to occur two
43 days after a Parrot monthly release.
44
45 =over 4
46
47 =item 1.
48
49 A few days before
50 the Parrot release, it's a good idea to:
51
52 =over 4
53
54 =item *
55
56 Remind people of the upcoming release, invite people to
57 update the ChangeLog file, update the ROADMAP, choose a
58 release name, etc.
59
60 =item *
61
62 Verify that the Parrot trunk head is able to build Rakudo
63 and run the spectest suite.
64
65 =item *
66
67 If Parrot's trunk exhibits any problems building or running
68 Rakudo (that require changes to Parrot to fix), immediately
69 report them to the Parrot development team so they can be
70 fixed prior to Parrot's release.
71
72 =item *
73
74 Review the RT queue for tickets that might need resolving
75 prior to the release, addressing them as needed.
76
77 =back
78
79 =item 2.
80
81 Once Parrot issues its monthly release, edit Rakudo's
82 build/PARROT_REVISION file to contain the subversion revision
4549f3c @pmichaud Minor update to docs for parrot release number in build/PARROT_REVISION.
pmichaud authored
83 number and release number corresponding to Parrot's monthly
84 release. For example, for June 2009 PARROT_REVISION file
85 contained "39599 1.3.0". As always, test to make sure Rakudo
86 still builds and passes its tests. Once build/PARROT_REVISION
87 has been set to the Parrot release, it must not be changed until
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
88 after the Rakudo release. In other words, we want each
89 monthly release of Rakudo to be able to be built using
90 the immediately prior release of Parrot.
91
92 =item 3.
93
94 The short period following the Parrot release until the
95 Rakudo release is generally intended for fixing bugs,
96 updating documentation, and so on.
97
98 =item 4.
99
100 As the actual release date nears, review the git log history
101 to see if any additional items need to be added to the ChangeLog.
102 This can be conveniently done with "git log --since=yyyy-mm-dd --reverse".
103
48c1791 @pmichaud More release_guide.pod improvements.
pmichaud authored
104 $ git commit docs/ChangeLog
105
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
106 =item 5.
107
108 When it's time to cut the release, create a new release announcement
109 in docs/announce/YYYY-MM. It's often a good idea to use the
110 previous month's file as a starting point for this. Highlight areas
111 in which the new release is significant. If possible, also give
112 some small details about the choice of release name. (If the
113 details are a bit lengthy, this can often best be done as a separate
114 section at the bottom of the announcement.)
115
48c1791 @pmichaud More release_guide.pod improvements.
pmichaud authored
116 $ git add docs/announce/YYYY-MM
117 $ git commit docs
118
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
119 =item 6.
120
121 Update the release dates and names at the top of this file
415514b @moritz [docs] more markup for release_guide.pod
moritz authored
122 (F<docs/release-guide.pod>). Also improve these instructions if
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
123 you find any steps that are missing.
124
48c1791 @pmichaud More release_guide.pod improvements.
pmichaud authored
125 $ git commit docs/release-guide.pod
126
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
127 =item 7.
128
129 Make sure everything compiles and runs from a known clean state:
130
131 $ make realclean
132 $ perl Configure.pl --gen-parrot
133 $ make
134 $ make test
135 $ make spectest
136
137 Continue adjusting things until make spectest passes as expected.
48c1791 @pmichaud More release_guide.pod improvements.
pmichaud authored
138 Often this means fixing a bug, fudging a test, or removing a
139 test from t/spectest.data . Use your best judgement or ask others
140 if uncertain what to do here.
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
141
142 =item 8.
143
144 Make sure any locally modified files have been pushed back to github.
145
48c1791 @pmichaud More release_guide.pod improvements.
pmichaud authored
146 $ git status
147 $ git push
148
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
149 =item 9.
150
19b8db2 @moritz sync Makefile and release_guide.pod about version formats.
moritz authored
151 Create an initial tarball by entering C<make release VERSION=YYYY-MM>,
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
152 where YYYY-MM is the month for which the release is being made.
153 This will create a candidate tarball file named <rakudo-YYYY-MM.tgz>.
154
155 =item 10.
156
157 Unpack the tar file into another area, and test that it
158 builds and runs properly. If there are any problems,
159 fix them and go back to step 7.
160
161 =item 11.
162
163 Tag the release by its release month ("MMMM-YY") and its code name.
164
165 $ git tag -a -m"tag release #nn" MMMM-YY # e.g., 2009-04
166 $ git tag -a -m"tag release #nn" CODENAME # e.g., "Bratislava"
79d0b9a @pmichaud Fix "git push --tags" in docs/release_guide.pod .
pmichaud authored
167 $ git push --tags
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
168
169 =item 12.
170
171 Upload the release tarball to github's download area at
415514b @moritz [docs] more markup for release_guide.pod
moritz authored
172 L<http://github.com/rakudo/rakudo/downloads>.
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
173
174 =item 13.
175
176 Publish the release announcement (from #5) above to appropriate
177 locations, including rakudo.org, use.perl, perl6-language,
178 perl6-announce, perl6-users, and others.
179
180 =item 14.
181
182 Update the Wikipedia entry at L<http://en.wikipedia.org/wiki/Rakudo>.
183
184 =item 15.
185
186 Promote the release anywhere else you think appropriate.
187
188 =item 16.
189
190 You're done! Celebrate with the appropriate amount of fun.
191
192 =back
381d26e @pmichaud Updates to docs/announce and docs/release_guide.pod .
pmichaud authored
193
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
194 =head1 COPYRIGHT
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
195
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
196 Copyright (C) 2009, The Perl Foundation.
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
197
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
198 =cut
2f3a8ab @pmichaud Update docs/release_guide.pod with typical steps for cutting a release.
pmichaud authored
199
f45384a @pmichaud First version of release_guide.pod, based on a proposed version
pmichaud authored
200 # Local Variables:
201 # fill-column: 100
202 # End:
203 # vim: expandtab shiftwidth=4:
Something went wrong with that request. Please try again.