Draft of the release notes

Author: rafaelfranca

guides/source/7_2_release_notes.md

@@ -5,6 +5,11 @@ Ruby on Rails 7.2 Release Notes
 
 Highlights in Rails 7.2:
 
+These release notes cover only the major changes. To learn about various bug
+fixes and changes, please refer to the changelogs or check out the [list of
+commits](https://github.com/rails/rails/commits/7-2-stable) in the main Rails
+repository on GitHub.
+
 --------------------------------------------------------------------------------
 
 Upgrading to Rails 7.2
@@ -21,6 +26,251 @@ guide.
 Major Features
 --------------
 
+### Development Containers configuration for applications
+
+A [development container](https://containers.dev/) (or dev container for short) allows you to use a container
+as a full-featured development environment.
+
+Rails 7.2 adds the ability to generate a development container configuration for your application. This configuration
+includes a `.devcontainer` folder with a `Dockerfile`, a `docker-compose.yml` file, and a `devcontainer.json` file.
+
+By default the dev container contains the following:
+
+* A redis container for use with Kredis, Action Cable etc.
+* A database (SQLite, Postgres, MySQL or MariaDB)
+* A Headless chrome container for system tests
+* Active Storage configured to use the local disk and with preview features working
+
+To generate a new application with a development container, you can run:
+
+```bash
+rails new myapp --devcontainer
+```
+
+For existing applications, a `devcontainer` command is now available:
+
+```bash
+rails devcontainer
+```
+
+For more information, see the [Getting Started with Dev Containers](https://edgeguides.rubyonrails.org/getting_started_with_devcontainer.html) guide.
+
+### Add browser version guard by default
+
+Rails now adds the ability to specify the browser versions that will be allowed to access all actions
+(or some, as limited by `only:` or `except:`).
+
+Only browsers matched in the hash or named set passed to `versions:` will be blocked if they're below the versions
+specified.
+
+This means that all other unknown browsers, as well as agents that aren't reporting a user-agent header, will be allowed access.
+
+A browser that's blocked will by default be served the file in `public/406-unsupported-browser.html` with a HTTP status
+code of "406 Not Acceptable".
+
+Examples:
+
+```ruby
+class ApplicationController < ActionController::Base
+  # Allow only browsers natively supporting webp images, web push, badges, import maps, CSS nesting + :has
+  allow_browser versions: :modern
+end
+
+class ApplicationController < ActionController::Base
+  # All versions of Chrome and Opera will be allowed, but no versions of "internet explorer" (ie). Safari needs to be 16.4+ and Firefox 121+.
+  allow_browser versions: { safari: 16.4, firefox: 121, ie: false }
+end
+
+class MessagesController < ApplicationController
+  # In addition to the browsers blocked by ApplicationController, also block Opera below 104 and Chrome below 119 for the show action.
+  allow_browser versions: { opera: 104, chrome: 119 }, only: :show
+end
+```
+
+For more information, see the [allow_browser](https://api.rubyonrails.org/classes/ActionController/AllowBrowser/ClassMethods.html#method-i-allow_browser)
+documentation.
+
+### Make Ruby 3.1 the new minimum version
+
+Until now, Rails only droped compatibility with older Rubies on new majors version.
+We are changing this policy because it causes us to keep compatibility with long
+unsupported versions of Ruby or to bump the Rails major version more often, and to
+drop multiple Ruby versions at once when we bump the major.
+
+Now we are going to drop Ruby versions on minor versions, following the recommendation
+from th Ruby team at the time of the release.
+
+For Rails 7.2, Ruby 3.1 is the new minimum version.
+
+### Default Progressive Web Application (PWA) files
+
+In preparation to better support creating PWA applications with Rails, we now generate default PWA files for manifest
+and service-worker that are served from `app/views/pwa` and can be dynamically rendered through ERB. Those files
+are mounted explicitly at the root with default routes in the generated routes file.
+
+For more information, see the [pull request adding the feature](https://github.com/rails/rails/pull/50528).
+
+### Add omakase RuboCop rules by default
+
+Rails applications now come with [RuboCop](https://rubocop.org/) configured with a set of rules from [rubocop-rails-omakase](https://github.com/rails/rubocop-rails-omakase) by default.
+
+Ruby is a beautifully expressive language that not only tolerates many different dialects, but celebrates their
+diversity. It was never meant as a language to be written exclusively in a single style across all libraries,
+frameworks, or applications. If you or your team has developed a particular house style that brings you joy,
+you should cherish that.
+
+This collection of Rubocop styles is for those who haven't committed to any specific dialect already. Who would just
+like to have a reasonable starting point, and who will benefit from some default rules to at least start a consistent
+approach to Ruby styling.
+
+These specific rules aren't right or wrong, but merely represent the idiosyncratic aesthetic sensibilities of Rails'
+creator. Use them whole, use them as a starting point, use them as inspiration, or however you see fit.
+
+### Add GitHub CI workflow by default to new applications
+
+Rails now adds a default GitHub CI workflow file to new applications. This will get especially newcomers off to a good
+start with automated scanning, linting, and testing. We find that a natural continuation for the modern age of what
+we've done since the start with unit tests.
+
+It's of course true that GitHub Actions are a commercial cloud product for private repositories after you've used the
+free tokens. But given the relationship with GitHub and Rails, the overwhelming default nature of the platform for
+newcomers, and the value of teaching newcomers good CI habits, We find this to be an acceptable trade-off.
+
+### Add Brakeman by default to new apps
+
+[Brakeman](https://brakemanscanner.org/) is a great way to prevent common security vulnerabilities in Rails from going
+into production.
+
+New application come with Brakeman installed and combined with the GitHub CI workflow, it will run automatically on
+every push.
+
+### Set a new default for the Puma thread count
+
+Rails changed the default number of threads in Puma from 5 to 3.
+
+Due to the nature of well optimized Rails applications, with quick SQL queries and slow 3rd party calls running via jobs,
+Ruby spends most of its time waiting for the Global VM Lock (GVL) to release when the thread count is too high.
+
+After careful consideration, investigation and based on battle tested experience from applications running in
+production, we decided that a default of 3 threads is a good balance between concurrency and performance.
+
+You can follow a very detailed discussion about this change in [the issue](https://github.com/rails/rails/issues/50450).
+
+### Prevent jobs from being scheduled within transactions
+
+A common mistake with Active Job is to enqueue jobs from inside a transaction, causing them to potentially be picked
+and ran by another process, before the transaction is committed, which result in various errors.
+
+```ruby
+Topic.transaction do
+  topic = Topic.create
+
+  NewTopicNotificationJob.perform_later(topic)
+end
+```
+
+Now Active Job will automatically defer the enqueuing to after the transaction is committed, and drop the job if the
+transaction is rolled back.
+
+Various queue implementations can chose to disable this behavior, and users can disable it, or force it on a per job
+basis:
+
+```ruby
+class NewTopicNotificationJob < ApplicationJob
+  self.enqueue_after_transaction_commit = false
+end
+```
+
+This is now possible due to a new feature that allows to register transaction callbacks outside of a record.
+
+`ActiveRecord::Base.transaction` now yields an `ActiveRecord::Transaction` object, which allows to register callbacks
+on it.
+
+```ruby
+Article.transaction do |transaction|
+  article.update(published: true)
+
+  transaction.after_commit do
+    PublishNotificationMailer.with(article: article).deliver_later
+  end
+end
+```
+
+`ActiveRecord::Base.current_transaction` was also added to allow to register callbacks on it.
+
+```ruby
+Article.current_transaction.after_commit do
+  PublishNotificationMailer.with(article: article).deliver_later
+end
+```
+
+And finally, `ActiveRecord.after_all_transactions_commit` was added, for code that may run either inside or outside a
+transaction and need to perform works after the state changes have been properly persisted.
+
+```ruby
+def publish_article(article)
+  article.update(published: true)
+
+  ActiveRecord.after_all_transactions_commit do
+    PublishNotificationMailer.with(article: article).deliver_later
+  end
+end
+```
+
+See the related pull requests for more information:
+
+https://github.com/rails/rails/pull/51474
+https://github.com/rails/rails/pull/51426
+
+### Enable YJIT by default if running Ruby 3.3+
+
+YJIT in Ruby's JIT compiler that is available in CRuby since Ruby 3.1. It can provide significant performance
+improvements for Rails applications, ranging 15-25% latency improvements.
+
+In Rails 7.2, YJIT is enabled by default if running Ruby 3.3 or newer.
+
+You can disable YJIT by setting:
+
+```ruby
+Rails.application.config.yjit = false
+```
+
+### New design for the Rails guides
+
+When Rails 7.0 landed in December 2021, it came with a fresh new homepage and a new boot screen. The design of the
+guides, however, has remained largely untouched since 2009 - a point which hasn’t gone unnoticed (we heard your feedback).
+
+With all of the work right now going into removing complexity from the Rails framework and making the documentation
+consistent, clear, and up-to-date, it was time to tackle the design of the guides and make them equally modern, simple,
+and fresh.
+
+We worked with UX designer [John Athayde](https://meticulous.com/) to take the look and feel of the homepage and
+transfer that over to the Rails Guide to make it clean, sleek, and up-to-date.
+
+The layout will remain the same, but from today you will see the following changes reflected in the Guides:
+
+* Cleaner, less busy design.
+* Fonts, color scheme, and logo more consistent with the home page.
+* Updated iconography.
+* Simplified navigation.
+* Sticky ‘Chapter’ navbar when scrolling.
+
+See the [announcement blog post for some before/after images](https://rubyonrails.org/2024/3/20/rails-guides-get-a-facelift).
+
+### Setup jemalloc in default Dockerfile to optimize memory allocation
+
+[Ruby's use of malloc can create memory fragmentation problems, especially when using multiple threads](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html)
+like Puma does. Switching to an allocator that uses different patterns to avoid fragmentation can decrease memory usage
+by a substantial margin.
+
+Rails 7.2 now includes jemalloc in the default Dockerfile to optimize memory allocation.
+
+### Suggest puma-dev configuration in bin/setup
+
+puma-dev is the golden path for developing multiple Rails applications locally, if you're not using Docker.
+
+Rails now suggests how to get that setup for apps with bin/setup.
+
 Railties
 --------
 
@@ -64,7 +314,7 @@ Please refer to the [Changelog][railties] for detailed changes.
 
 *   System tests now use headless Chrome by default for new applications.
 
-*   Support the `BACKTRACE` environment variable to turn off backtrace cleaning in normal server runnings. 
+*   Support the `BACKTRACE` environment variable to turn off backtrace cleaning in normal server runnings.
     Previously, this was only available for the testing.
 
 *   Add default Progressive Web App (PWA) files for the manifest and service worker, served from `app/views/pwa`,

guides/source/documents.yaml

@@ -335,7 +335,6 @@
       name: Version 7.2 - ?
       url: 7_2_release_notes.html
       description: Release notes for Rails 7.2.
-      work_in_progress: true
     -
       name: Version 7.1 - October 2023
       url: 7_1_release_notes.html