Skip to content
Newer
Older
100644 191 lines (124 sloc) 5.98 KB
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
1 = Releasing Rails
2
3 In this document, we'll cover the steps necessary to release Rails. Each
4 section contains steps to take during that time before the release. The times
5 suggested in each header are just that: suggestions. However, they should
6 really be considered as minimums.
7
8 == 10 Days before release
9
10 Today is mostly coordination tasks. Here are the things you must do today:
11
12 === Is the CI green? If not, make it green. (See "Fixing the CI")
13
14 Do not release with a Red CI. You can find the CI status here:
15
16 http://travis-ci.org/#!/rails/rails
17
18 === Is Sam Ruby happy? If not, make him happy.
19
20 Sam Ruby keeps a test suite that makes sure the code samples in his book (Agile
21 Web Development with Rails) all work. These are valuable integration tests
22 for Rails. You can check the status of his tests here:
23
24 http://intertwingly.net/projects/dashboard.html
25
26 Do not release with Red AWDwR tests.
27
28 === Do we have any git dependencies? If so, contact those authors.
29
30 Having git dependencies indicates that we depend on unreleased code.
31 Obviously rails cannot be released when it depends on unreleased code.
32 Contact the authors of those particular gems and work out a release date that
f566fb3 @waynn "suits" is correct here, not "suites"
waynn authored
33 suits them.
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
34
5399b20 @tenderlove moving CI and Sam Ruby to the top of the list. I :heart: CI and Sam
tenderlove authored
35 === Contact the security team (either Koz or tenderlove)
36
37 Let them know of your plans to release. There may be security issues to be
38 addressed, and that can impact your release date.
39
40 === Notify implementors.
41
42 Ruby implementors have high stakes in making sure Rails works. Be kind and
43 give them a heads up that Rails will be released soonish.
44
45 Send an email just giving a heads up about the upcoming release to these
46 lists:
47
48 * team@jruby.org
49 * community@rubini.us
50 * rubyonrails-core@googlegroups.com
51
52 Implementors will love you and help you.
53
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
54 == 3 Days before release
55
56 This is when you should release the release candidate. Here are your tasks
57 for today:
58
59 === Is the CI green? If not, make it green.
60
61 === Is Sam Ruby happy? If not, make him happy.
62
63 === Contact the security team. CVE emails must be sent on this day.
64
65 === Create a release branch.
66
67 From the stable branch, create a release branch. For example, if you're
68 releasing Rails 3.0.10, do this:
69
70 [aaron@higgins rails (3-0-stable)]$ git checkout -b 3-0-10
71 Switched to a new branch '3-0-10'
72 [aaron@higgins rails (3-0-10)]$
73
74 === Update each CHANGELOG.
75
76 Many times commits are made without the CHANGELOG being updated. You should
77 review the commits since the last release, and fill in any missing information
78 for each CHANGELOG.
79
80 You can review the commits for the 3.0.10 release like this:
81
82 [aaron@higgins rails (3-0-10)]$ git log v3.0.9..
83
c7b8468 @jonleighton Add note about syncing CHANGELOGs
jonleighton authored
84 If you're doing a stable branch release, you should also ensure that all of
85 the CHANGELOG entries in the stable branch are also synced to the master
86 branch.
87
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
88 === Update the RAILS_VERSION file to include the RC.
89
90 === Release the gem.
91
92 IMPORTANT: Due to YAML parse problems on the rubygems.org server, it is safest
93 to use Ruby 1.8 when releasing.
94
95 Run `rake release`. This will populate the gemspecs with data from
96 RAILS_VERSION, commit the changes, tag it, and push the gems to rubygems.org.
97 Here are the commands that `rake release` should use, so you can understand
98 what to do in case anything goes wrong:
99
100 $ rake all:build
101 $ git commit -am'updating RAILS_VERSION'
102 $ git tag -m'tagging rc release' v3.0.10.rc1
5852fcf @spastorino Add git push and git push --tags to RELEASING_RAILS.rdoc
spastorino authored
103 $ git push
104 $ git push --tags
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
105 $ for i in $(ls dist); do gem push $i; done
106
107 === Send Rails release announcements
108
109 Write a release announcement that includes the version, changes, and links to
110 github where people can find the specific commit list. Here are the mailing
111 lists where you should announce:
112
113 * rubyonrails-core@googlegroups.com
114 * rubyonrails-talk@googlegroups.com
115 * ruby-talk@ruby-lang.org
116
117 Use markdown format for your announcement. Remember to ask people to report
118 issues with the release candidate to the rails-core mailing list.
119
886d011 @tenderlove fixing wrong words. thanks @jbrown
tenderlove authored
120 IMPORTANT: If any users experience regressions when using the release
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
121 candidate, you *must* postpone the release. Bugfix releases *should not*
122 break existing applications.
123
124 === Post the announcement to the Rails blog.
125
126 If you used markdown format for your email, you can just paste it in to the
127 blog.
128
129 * http://weblog.rubyonrails.org
130
131 === Post the announcement to the Rails twitter account.
132
133 == Time between release candidate and actual release
134
135 Check the rails-core mailing list and the github issue list for regressions in
136 the RC.
137
138 If any regressions are found, fix the regressions and repeat the release
139 candidate process. We will not release the final until 72 hours after the
140 last release candidate has been pushed. This means that if users find
141 regressions, the scheduled release date must be postponed.
142
143 When you fix the regressions, do not create a new branch. Fix them on the
144 stable branch, then cherry pick the commit to your release branch. No other
145 commits should be added to the release branch besides regression fixing commits.
146
147 == Day of release
148
149 Many of these steps are the same as for the release candidate, so if you need
150 more explanation on a particular step, so the RC steps.
151
22e611e @tenderlove making the order more clear, adding linux distros mailing lists to ou…
tenderlove authored
152 Today, do this stuff in this order:
153
154 * Apply security patches to the release branch
155 * Update CHANGELOG with security fixes.
156 * Update RAILS_VERSION to remove the rc
157 * Release the gems
158 * Email security lists
159 * Email general announcement lists
9d9f591 @tenderlove adding lessons learned so I do not make the same mistake twice
tenderlove authored
160
22e611e @tenderlove making the order more clear, adding linux distros mailing lists to ou…
tenderlove authored
161 === Emailing the rails security announce list
9d9f591 @tenderlove adding lessons learned so I do not make the same mistake twice
tenderlove authored
162
22e611e @tenderlove making the order more clear, adding linux distros mailing lists to ou…
tenderlove authored
163 Email the security announce list once for each vulnerability fixed.
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
164
165 You can do this, or ask the security team to do it.
166
22e611e @tenderlove making the order more clear, adding linux distros mailing lists to ou…
tenderlove authored
167 Email the security reports to:
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
168
22e611e @tenderlove making the order more clear, adding linux distros mailing lists to ou…
tenderlove authored
169 * rubyonrails-security@googlegroups.com
170 * linux-distros@vs.openwall.org
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
171
172 Be sure to note the security fixes in your announcement along with CVE numbers
173 and links to each patch. Some people may not be able to upgrade right away,
174 so we need to give them the security fixes in patch form.
175
176 * Blog announcements
177 * Twitter announcements
178 * Merge the release branch to the stable branch.
179 * Drink beer (or other cocktail)
180
181 == Misc
182
183 === Fixing the CI
184
185 There are two simple steps for fixing the CI:
186
187 1. Identify the problem
188 2. Fix it
189
190 Repeat these steps until the CI is green.
Something went wrong with that request. Please try again.