Modern CMS projects publish a release schedule, so you can plan instead of asking when the next version arrives. Semantic versioning signals the risk: patch releases fix bugs, minor releases add features compatibly, major releases may break things. Check the support window for your version and book upgrades before it ends.
From the original phpWordPress forum · archived copy
a forum member ·
In this month or in this weekend? :-) We are waiting for this milestone.
phpWordPress staff (Moderator) ·
The release date for 3.2 is approaching fast. Expect a PR blitzkrieg early next week!
a forum member ·
Any update on this? We are waiting for this milestone as well.
phpWordPress staff (Moderator) ·
Yes, today is the official release party! We are having a few drinks to celebrate, see the press release above. Quote:
phpWordPress staff (Product Line Manager) ·
All the customers will find download link for the Upgrade in their Administration Panels today. If you're having problems upgrading your version of phpWordPress please contact Support team on [email removed], or thru HelpDesk [link removed]
View the archived thread on the Wayback Machine. Usernames and contact details have been removed.
In April and May 2006 customers asked repeatedly when phpWordPress 3.2 would ship. Staff said the date was close, and the release arrived on 8 May with the upgrade in each customer’s admin panel. Today the better question is where the project publishes its schedule, because most serious CMS projects do.
What does a version number tell me?
Semantic Versioning, the convention many projects follow, defines three parts. The MAJOR number rises for incompatible API changes. The MINOR number rises for functionality added in a backward compatible manner. The PATCH number rises for backward compatible bug fixes. A 0.y.z version is for initial development, and the specification says anything may change at any time.
| Change | Example | Risk to your site | Typical response |
|---|---|---|---|
| Patch | 3.2.0 to 3.2.1 | Low | Apply promptly after a backup |
| Minor | 3.2 to 3.3 | Moderate; new features, some deprecations | Test on staging, upgrade in weeks |
| Major | 3.x to 4.0 | High; breaking changes possible | Project it, budget it, test it fully |
Semantic Versioning is a convention about programming interfaces, and a CMS also has themes, plugins and content to consider. Read each project’s own policy before assuming a minor release is harmless to your customisations.
How does a published release cycle work in practice?
Drupal publishes one of the clearest schedules, so it makes a useful example. According to its release process overview:
| Release type | Cadence | Support |
|---|---|---|
| Major | Every two years, in even years | At least 4 years, until two further major versions are released |
| Minor | About every six months, in June and December | One year: bug and security fixes for six months, then security fixes only for six months |
| Patch | Monthly | Non-disruptive bug fixes only |
| LTS phase | Begins when a new major arrives | A maintenance minor for the previous major every six months |
Drupal’s schedule also says security release windows will usually fall on the third Wednesday of the month, and it lists Drupal 10 reaching end of life on December 9, 2026, with Drupal 12.0.0 planned for the week of December 7, 2026. The schedule page is the source to check, since dates can shift.
The pattern to look for in any CMS is the same: how often do releases come, how long is each supported, and what is the rule for security fixes after support ends? WordPress documents that minor core updates, such as maintenance and security releases, are applied automatically by default, which shifts some of the planning work onto the software itself.
What is a support window and why does it matter?
A support window is the period in which the project issues fixes for a version. After it ends, you can keep running the version, but newly found vulnerabilities will not be fixed for you. For a publisher, the practical effect is a deadline: before the end-of-life date, you must be on a supported version, or be prepared to pay for support from a third party.
Write down three dates for every site you run: the date your current version stops getting bug fixes, the date it stops getting security fixes, and the date the next major arrives. Those dates, not the vendor’s marketing calendar, drive your plan. Our release history shows how a project’s versions can be laid out in order.
How should I plan upgrades?
- Inventory. List the CMS version, themes, plugins and custom code, as described in our answer on security patches.
- Set a rhythm. Apply patch releases monthly or sooner for security fixes. Review minor releases twice a year. Review the major-version roadmap annually.
- Check compatibility early. Before each major upgrade, check that each plugin and theme has a compatible release. Replace abandoned ones before upgrade day, not on it.
- Back up, then stage. WordPress documentation advises backing up the database regularly and always before an upgrade. Run the upgrade on a staging copy first.
- Schedule around the news cycle. Avoid election nights, budget days and other predictable traffic peaks. Pick a quiet period and have a rollback ready.
- Keep customisations upgrade-safe. Overrides in a child theme or hooks cost less to carry than edits to core, as covered in our answer on safe customisation.
How do I read release notes before upgrading?
Open the notes for every release between your version and the target, not only the last one. Look for four things: removed or deprecated features that your plugins or templates use, renamed template files or hooks, minimum requirements such as the PHP or database version, and database updates that must run during the upgrade. Mark each item that touches something you have customised, and test those first on staging. If a release note says an interface is deprecated, treat that as a to-do for your next minor upgrade, not a reason to ignore it, since a later major release may remove it.
What if my CMS has no published schedule?
Treat that as a risk factor. Ask the vendor how long each version is supported, how security fixes are announced, and whether older versions get fixes after a new major. A vendor who cannot answer is telling you the plan will be yours to make. If you are comparing products, add “published support policy” to your feature checklist, and see our cost guide for where upgrade work fits in the budget.
What if I am several versions behind?
Do not jump straight to the latest. Check the project’s upgrade documentation for supported upgrade paths, which often require stepping through specific versions. Take a full backup, rehearse on staging, and budget more time for custom code. Being behind is common. What matters is knowing how far, and what the oldest supported version is.
Questions people ask
What do the numbers in a version like 3.2.1 mean?
Under Semantic Versioning the first number is the major version, for incompatible changes, the second is the minor version, for backward compatible features, and the third is the patch, for backward compatible bug fixes. Not every CMS follows the scheme strictly, so read the project's own policy.
How often should I upgrade my CMS?
Apply patch and security releases promptly, on a schedule you set. Plan minor upgrades a few times a year and major upgrades before your current major reaches end of life. Drupal, for example, publishes monthly patch releases and minor releases about every six months.
What happens when my version reaches end of life?
The project stops issuing fixes for it, including security fixes, so new vulnerabilities in that version stay open. Drupal 10 is scheduled to reach end of life on December 9, 2026. Plan the move to a supported version well before the date.
Is there a long-term support version of my CMS?
It depends on the project. Drupal describes an LTS phase that begins when a new major release arrives, with maintenance minors for the previous major every six months. Check your vendor's documentation for the support window of your exact version.
Sources
- Semantic Versioning defines a MAJOR version for incompatible API changes, a MINOR version for functionality added in a backward compatible manner, and a PATCH version for backward compatible bug fixes. — source, checked 10 October 2026.
- Semantic Versioning says major version zero (0.y.z) is for initial development and that anything may change at any time. — source, checked 10 October 2026.
- Drupal's release process overview says new major versions are released every two years, in even years, and each major version is supported for a minimum of 4 years, until the release of two further major versions. — source, checked 10 October 2026.
- Drupal's release process overview says new minor versions are released approximately every six months, in June and December. — source, checked 10 October 2026.
- Drupal's release process overview says each minor version is supported for one year, with bug and security fixes for the first six months and security fixes only for the last six months. — source, checked 10 October 2026.
- Drupal's release process overview says patch versions are released monthly and only contain non-disruptive bug fixes, so site owners can safely upgrade their applications. — source, checked 10 October 2026.
- Drupal's release process overview says that when a new major version is released, a corresponding minor with the same API is released for the previous major, beginning the Long-Term Support phase, during which a maintenance minor is released every six months. — source, checked 10 October 2026.
- Drupal's core release schedule states that Drupal 10 will reach end of life on December 9, 2026. — source, checked 10 October 2026.
- Drupal's core release schedule lists the Drupal 12.0.0 release for the week of December 7, 2026. — source, checked 10 October 2026.
- Drupal's core release schedule says security release windows will usually be on the third Wednesday of the month. — source, checked 10 October 2026.
- WordPress documentation says minor core updates, such as maintenance and security releases, are applied automatically by default. — source, checked 10 October 2026.
- WordPress documentation advises backing up the database regularly and always before an upgrade. — source, checked 10 October 2026.