kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

Upgrade Release guide to match current practices

Browse source
This commit is contained in:
Rafael Mendonça França 2022-05-18 23:04:29 +00:00
parent 804a861162
commit 42e99b2c64
No known key found for this signature in database
GPG key ID: FC23B6D0F1EEE948
1 changed files with 5 additions and 85 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

90
RELEASING_RAILS.md
View file

@ -17,18 +17,6 @@ Do not release with a Red CI. You can find the CI status here:
https://buildkite.com/rails/rails
```
### Is Sam Ruby happy? If not, make him happy.
Sam Ruby keeps a [test suite](https://github.com/rubys/awdwr) that makes
sure the code samples in his book
([Agile Web Development with Rails](https://pragprog.com/titles/rails6))
all work. These are valuable system tests
for Rails. You can check the status of these tests here:
[https://intertwingly.net/projects/dashboard.html](https://intertwingly.net/projects/dashboard.html)
Do not release with Red AWDwR tests.
### Do we have any Git dependencies? If so, contact those authors.
Having Git dependencies indicates that we depend on unreleased code.
@ -36,49 +24,9 @@ Obviously Rails cannot be released when it depends on unreleased code.
Contact the authors of those particular gems and work out a release date that
suits them.
### Contact the security team (either tenderlove or rafaelfranca)
### Announce your plans to the rest of the team on Campfire
Let them know of your plans to release. There may be security issues to be
addressed, and that can impact your release date.
### Notify implementors.
Ruby implementors have high stakes in making sure Rails works. Be kind and
give them a heads up that Rails will be released soonish.
This is only required for major and minor releases, bugfix releases aren't a
big enough deal, and are supposed to be backward compatible.
Send a message just giving a heads up about the upcoming release to these
lists:
* team@jruby.org
* community@rubini.us
* [rubyonrails-core](https://discuss.rubyonrails.org/c/rubyonrails-core)
Implementors will love you and help you.
## 3 Days before release
This is when you should release the release candidate. Here are your tasks
for today:
### Is the CI green? If not, make it green.
### Is Sam Ruby happy? If not, make him happy.
### Contact the security team. CVE emails must be sent on this day.
### Create a release branch.
From the stable branch, create a release branch. For example, if you're
releasing Rails 3.0.10, do this:
```
[aaron@higgins rails (3-0-stable)]$ git checkout -b 3-0-10
Switched to a new branch '3-0-10'
[aaron@higgins rails (3-0-10)]$
```
Let them know of your plans to release.
### Update each CHANGELOG.
@ -96,6 +44,8 @@ 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 main
branch.
## Day of release
### Put the new version in the RAILS_VERSION file.
Include an RC number if appropriate, e.g. `6.0.0.rc1`.
@ -162,37 +112,7 @@ blog.
### Post the announcement to the Rails Twitter account.
## Time between release candidate and actual release
Check the rails-core mailing list and the GitHub issue list for regressions in
the RC.
If any regressions are found, fix the regressions and repeat the release
candidate process. We will not release the final until 72 hours after the
last release candidate has been pushed. This means that if users find
regressions, the scheduled release date must be postponed.
When you fix the regressions, do not create a new branch. Fix them on the
stable branch, then cherry pick the commit to your release branch. No other
commits should be added to the release branch besides regression fixing commits.
## Day of release
Many of these steps are the same as for the release candidate, so if you need
more explanation on a particular step, see the RC steps.
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
* If releasing a new stable version:
- Trigger stable docs generation (see below)
- Update the version in the home page
* Email security lists
* Email general announcement lists
## Security releases
### Emailing the Rails security announce list