Among the many release strategies, there are two I find especially critical: code freeze and release windows. A code freeze is a period of time when the code cannot change except for critical patches. A release window is a period of time when production releases cannot happen except for critical patches. They are closely related, but not the same.
The purpose of a code freeze is to control testing. QA knows exactly what is going to be released, there are no last-minute changes, no half-baked hidden features, there is time to test every aspect and integration, and the whole process can be very clean. A code freeze is best implemented with release branches that stem from the main branch, with cherry-picking to add patches. It’s also possible to have multiple release branches at the same time to prepare multiple versions. The team is never blocked, because it is always possible to merge new features, though there is some overhead in managing the branches.
The purpose of release windows is instead to protect production from release-related incidents. They are useful for blocking releases during traffic peaks or moments of particular significance for the business. They can last hours or days. The team is never blocked, because they can always merge more features. But if the code freeze lasts for a long time (several days or weeks), the team piles up changes and ends up doing a big bang release. That becomes critical when there is a potentially dangerous commit, such as a database migration or a switch in some integration, because it may be hard to isolate that commit in one release, and it may be impossible to fall forward by fixing a small problem instead of reverting the whole release. It also causes the team to hold risky merges for longer, forcing them to rebase many times.
Both practices put pressure on the team. Code freezes cause the team to rush to include a feature before the cutoff, and release windows cause the team to rush before the cutoff and then do big bangs after long periods of blocked releases. However, while a code freeze is a practice to ensure quality, release windows are an anti-pattern driven by fear of problems. Implementing release windows is like admitting an inability to control quality and choosing to minimise the impact of a failed release instead of learning to have solid releases.
In my experience, code freezes have, overall, more advantages than disadvantages, and they still give teams a lot of freedom to manage things properly. Release windows can be okay, but only if they are occasional and short: a few days a month is not a problem, a week a month can be easily managed, but two or more weeks a month or a checkerboard pattern are more of a problem than anything.