aboutsummaryrefslogtreecommitdiffstats
path: root/RELEASING_RAILS.rdoc
diff options
context:
space:
mode:
Diffstat (limited to 'RELEASING_RAILS.rdoc')
-rw-r--r--RELEASING_RAILS.rdoc65
1 files changed, 58 insertions, 7 deletions
diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc
index 4a9a875bfa..7a77f9bba2 100644
--- a/RELEASING_RAILS.rdoc
+++ b/RELEASING_RAILS.rdoc
@@ -81,8 +81,20 @@ You can review the commits for the 3.0.10 release like this:
[aaron@higgins rails (3-0-10)]$ git log v3.0.9..
+If you're doing a stable branch release, you should also ensure that all of
+the CHANGELOG entries in the stable branch are also synced to the master
+branch.
+
=== Update the RAILS_VERSION file to include the RC.
+=== Build and test the gem.
+
+Run `rake install` to generate the gems and install them locally. Then try
+generating a new app and ensure that nothing explodes.
+
+This will stop you from looking silly when you push an RC to rubygems.org and
+then realise it is broken.
+
=== Release the gem.
IMPORTANT: Due to YAML parse problems on the rubygems.org server, it is safest
@@ -145,18 +157,26 @@ commits should be added to the release branch besides regression fixing commits.
Many of these steps are the same as for the release candidate, so if you need
more explanation on a particular step, so the RC steps.
-=== Email the rails security announce list, once for each vulnerability fixed.
-
-You can do this, or ask the security team to do it.
-
-FIXME: I can't remember the email addresses, but we should list them here.
-FIXME: Possibly we should do this the day of the RC?
+Today, do this stuff in this order:
* Apply security patches to the release branch
* Update CHANGELOG with security fixes.
* Update RAILS_VERSION to remove the rc
+* Build and test the gem
* Release the gems
-* Email announcement
+* Email security lists
+* Email general announcement lists
+
+=== Emailing the rails security announce list
+
+Email the security announce list once for each vulnerability fixed.
+
+You can do this, or ask the security team to do it.
+
+Email the security reports to:
+
+* rubyonrails-security@googlegroups.com
+* linux-distros@vs.openwall.org
Be sure to note the security fixes in your announcement along with CVE numbers
and links to each patch. Some people may not be able to upgrade right away,
@@ -177,3 +197,34 @@ There are two simple steps for fixing the CI:
2. Fix it
Repeat these steps until the CI is green.
+
+=== Manually trigger docs generation
+
+We have a post-receive hook in GitHub that calls the docs server on pushes.
+It triggers generation and publication of edge docs, updates the contrib app,
+and generates and publishes stable docs if a new stable tag is detected.
+
+The hook unfortunately is not invoked by tag pushing, so once the new stable
+tag has been pushed to origin, please run
+
+ rake publish_docs
+
+You should see something like this:
+
+ Rails master hook tasks scheduled:
+
+ * updates the local checkout
+ * updates Rails Contributors
+ * generates and publishes edge docs
+
+ If a new stable tag is detected it also
+
+ * generates and publishes stable docs
+
+ This needs typically a few minutes.
+
+Note you do not need to specify the tag, the docs server figures it out.
+
+Also, don't worry if you call that multiple times or the hook is triggered
+again by some immediate regular push, if the scripts are running new calls
+are just queued (in a queue of size 1).