Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 164 lines (106 sloc) 5.482 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 === Contact the security team (either Koz or tenderlove)
13
14 Let them know of your plans to release. There may be security issues to be
15 addressed, and that can impact your release date.
16
17 === Is the CI green? If not, make it green. (See "Fixing the CI")
18
19 Do not release with a Red CI. You can find the CI status here:
20
21 http://travis-ci.org/#!/rails/rails
22
23 === Is Sam Ruby happy? If not, make him happy.
24
25 Sam Ruby keeps a test suite that makes sure the code samples in his book (Agile
26 Web Development with Rails) all work. These are valuable integration tests
27 for Rails. You can check the status of his tests here:
28
29 http://intertwingly.net/projects/dashboard.html
30
31 Do not release with Red AWDwR tests.
32
33 === Do we have any git dependencies? If so, contact those authors.
34
35 Having git dependencies indicates that we depend on unreleased code.
36 Obviously rails cannot be released when it depends on unreleased code.
37 Contact the authors of those particular gems and work out a release date that
38 suites them.
39
40 == 3 Days before release
41
42 This is when you should release the release candidate. Here are your tasks
43 for today:
44
45 === Is the CI green? If not, make it green.
46
47 === Is Sam Ruby happy? If not, make him happy.
48
49 === Contact the security team. CVE emails must be sent on this day.
50
51 === Create a release branch.
52
53 From the stable branch, create a release branch. For example, if you're
54 releasing Rails 3.0.10, do this:
55
56 [aaron@higgins rails (3-0-stable)]$ git checkout -b 3-0-10
57 Switched to a new branch '3-0-10'
58 [aaron@higgins rails (3-0-10)]$
59
60 === Update each CHANGELOG.
61
62 Many times commits are made without the CHANGELOG being updated. You should
63 review the commits since the last release, and fill in any missing information
64 for each CHANGELOG.
65
66 You can review the commits for the 3.0.10 release like this:
67
68 [aaron@higgins rails (3-0-10)]$ git log v3.0.9..
69
70 === Update the RAILS_VERSION file to include the RC.
71
72 === Release the gem.
73
74 IMPORTANT: Due to YAML parse problems on the rubygems.org server, it is safest
75 to use Ruby 1.8 when releasing.
76
77 Run `rake release`. This will populate the gemspecs with data from
78 RAILS_VERSION, commit the changes, tag it, and push the gems to rubygems.org.
79 Here are the commands that `rake release` should use, so you can understand
80 what to do in case anything goes wrong:
81
82 $ rake all:build
83 $ git commit -am'updating RAILS_VERSION'
84 $ git tag -m'tagging rc release' v3.0.10.rc1
85 $ for i in $(ls dist); do gem push $i; done
86
87 === Send Rails release announcements
88
89 Write a release announcement that includes the version, changes, and links to
90 github where people can find the specific commit list. Here are the mailing
91 lists where you should announce:
92
93 * rubyonrails-core@googlegroups.com
94 * rubyonrails-talk@googlegroups.com
95 * ruby-talk@ruby-lang.org
96
97 Use markdown format for your announcement. Remember to ask people to report
98 issues with the release candidate to the rails-core mailing list.
99
886d011 @tenderlove fixing wrong words. thanks @jbrown
tenderlove authored
100 IMPORTANT: If any users experience regressions when using the release
6b80917 @tenderlove adding my brain dump of the release process
tenderlove authored
101 candidate, you *must* postpone the release. Bugfix releases *should not*
102 break existing applications.
103
104 === Post the announcement to the Rails blog.
105
106 If you used markdown format for your email, you can just paste it in to the
107 blog.
108
109 * http://weblog.rubyonrails.org
110
111 === Post the announcement to the Rails twitter account.
112
113 == Time between release candidate and actual release
114
115 Check the rails-core mailing list and the github issue list for regressions in
116 the RC.
117
118 If any regressions are found, fix the regressions and repeat the release
119 candidate process. We will not release the final until 72 hours after the
120 last release candidate has been pushed. This means that if users find
121 regressions, the scheduled release date must be postponed.
122
123 When you fix the regressions, do not create a new branch. Fix them on the
124 stable branch, then cherry pick the commit to your release branch. No other
125 commits should be added to the release branch besides regression fixing commits.
126
127 == Day of release
128
129 Many of these steps are the same as for the release candidate, so if you need
130 more explanation on a particular step, so the RC steps.
131
132 === Email the rails security announce list, once for each vulnerability fixed.
133
134 You can do this, or ask the security team to do it.
135
136 FIXME: I can't remember the email addresses, but we should list them here.
137 FIXME: Possibly we should do this the day of the RC?
138
139 * Apply security patches to the release branch
140 * Update CHANGELOG with security fixes.
141 * Update RAILS_VERSION to remove the rc
142 * Release the gems
143 * Email announcement
144
145 Be sure to note the security fixes in your announcement along with CVE numbers
146 and links to each patch. Some people may not be able to upgrade right away,
147 so we need to give them the security fixes in patch form.
148
149 * Blog announcements
150 * Twitter announcements
151 * Merge the release branch to the stable branch.
152 * Drink beer (or other cocktail)
153
154 == Misc
155
156 === Fixing the CI
157
158 There are two simple steps for fixing the CI:
159
160 1. Identify the problem
161 2. Fix it
162
163 Repeat these steps until the CI is green.
Something went wrong with that request. Please try again.