Rocket.Chat follows a structured release lifecycle, adhering to semantic versioning (Major.Minor.Patch) for its version numbers. Each type of release – Major, Minor, Patch, and Long-Term Support (LTS) – serves a specific purpose and comes with defined support timelines. This document provides an overview of these release types, their support durations, the LTS policy, end-of-life implications, and best practices for upgrades and maintenance.
Release types, versioning & expected content
Release Type and Version Pattern | What It Is | What It Includes |
|---|---|---|
Major Release: Indicated by a bump in the first digit of the version, e.g., v6.0.0 → v7.0.0 | A foundational upgrade that can introduce breaking changes (new system requirements, deprecated features, database migrations, etc.). Treat as a planned event. | • Significant new or overhauled features, performance, or architecture changes. • All cumulative fixes from prior minors and patches. • May demand configuration updates, client‑side upgrades, or extra regression testing. |
Minor Release: Increments the second digit of the version, e.g., v6.1.0 → v6.2.0 | Feature‑bearing, backward‑compatible update within the same major line. | • New or enhanced capabilities (integrations, admin settings, UI/UX optimisations). • Performance, stability, and security improvements. • May deprecate features to be removed in the next major, but does not break existing integrations in the same major series. |
Patch Release: Changes the third digit of the version, e.g., v6.1.1 → v6.1.2 | Rapid, low‑risk update aimed at stability and security. Safe to apply quickly. | • Bug fixes for regressions or defects in the current major/minor. • Security vulnerability patches (and vulnerable dependency updates exploitable in Rocket.Chat). • Occasional trivial tweaks (e.g., a translation string) that carry no functional risk. • No new features or behavioural changes. |
Long‑Term Support (LTS) Release: Regular semantic version (often final minor in a major series) explicitly tagged “LTS” in release notes. | Feature‑complete baseline with an extended support window. | • All features up to the LTS declaration date. • Post‑LTS updates are patch‑only (critical bug & security fixes). • No new features or minor enhancements after LTS goes into maintenance mode, ensuring maximum stability for organisations that upgrade infrequently. |
Understanding both the version bump and the expected content for each release type lets administrators plan upgrades, allocate testing resources, and balance innovation against operational risk.
Support duration by release type
Rocket.Chat provides time-bound support windows for each release. It receives security updates and critical fixes during a release's support window. Once the window closes, the release is considered end-of-life (EOL) and is no longer supported. Table beloe summarizes the support duration for each type of release:
Release Type | Example Version | Support Duration | What it means |
|---|---|---|---|
Major Release | v6.0.0 (standard) | 6 months from its release date (if LTS, see LTS row) | In practical terms, this means if a version (major or minor) is released in January, it will receive official updates and support until the last day of April 30 of that year. Administrators should plan to upgrade to a newer release within that 3-month window to remain on a supported version. |
Minor Release | v6.1.0 (standard) | 6 months from its release date (same as major) | |
Patch Release | v6.1.1 | N/A (Patches inherit the support window of their base Major or Minor release) | Patch releases do not have separate support timelines from their parent release. When a patch (e.g., 6.1.1) is issued, it falls under the same support window as the minor (6.1.0) or major version it patches. In other words, patch releases do not extend the support period; they only provide fixes within the existing window. |
LTS Release | v6.5 (LTS) | 9 months from its release date (Long-term support window) | Rocket.Chat ships about two LTS releases per year, each supported for nine months—longer than standard versions—so teams can stay secure without constant upgrades. The schedules overlap by roughly three months, giving admins a built‑in window to test and migrate to the new LTS before the previous one reaches EOL. |
Security fixes—including vulnerability patches and related dependency updates—will be delivered and backported to both LTS and regular versions during their support period. Note that only fixes for dependencies with exploitable vulnerabilities within Rocket.Chat will be backported.
Long-term support (LTS) policy and usage
Cadence: Rocket.Chat plans to maintain two LTS releases per year (roughly one every six months). This predictable cadence allows organizations to plan upgrades in advance. Not every major release may be LTS; typically, LTS designation is given to selected releases that meet stability criteria. Often, an LTS will coincide with a major release that is considered mature, or the final minor update on a major line, ensuring it includes a broad set of features and fixes up to that point.
Support Window: Each LTS release is supported for 9 months. This extended window includes all the content of that release, plus any patch updates (security and critical fixes) for the duration. The 9-month span is designed to balance the need for stability with the project’s fast-paced development – it’s long enough to reduce upgrade frequency (compared to every 6 months for standard releases) but short enough that the software stays reasonably up-to-date. With two LTS releases per year, there will usually be an overlap where two LTS versions are supported concurrently. This overlap (typically a few months) is intentionally provided so administrators running an older LTS have time to migrate to the newer LTS before the older one expires.
Intended Use Cases: LTS releases are ideal for deployments where stability and long-term maintenance are the priority – for example, enterprise environments, critical production systems, or organizations with strict change control processes. By adopting every second LTS, an organization could, for instance, do two planned Rocket.Chat upgrades per year and remain fully supported. LTS versions receive only maintenance updates (no new features) during their lifespan, which means behavior stays consistent; this predictability is valuable for integration testing and user training. However, using an LTS also means foregoing the newest features until the next upgrade. Therefore, some organizations may choose to run on LTS for core reliability, while others may track standard releases to access new features sooner.
Security fixes are backported to LTS releases, while security enhancements and new features are available only in standard releases (Major or Minor).
An LTS release allows you to delay full version upgrades while continuing to receive patches for verified vulnerabilities. It's ideal for environments where frequent updates are challenging but maintaining essential security is critical.
Depending exclusively on LTS versions may result in non-security issues going unresolved.
Security fixes vs. security improvements
Rocket.Chat’s release notes often distinguish between “Security Fixes” and “Security Improvements.” It’s important to understand the difference:
Security Fixes refer to patches that address specific identified security vulnerabilities or bugs. These are reactive fixes for issues that could compromise the system’s security (for example, a fix for an XSS vulnerability, a patch for an authentication bypass bug, etc.). Security fixes are critical in nature – they resolve known weaknesses that could be exploited. When Rocket.Chat issues a security fix, it is usually given top priority in patch releases because it directly safeguards against attacks.
Security Improvements are changes that enhance the overall security posture of the application, but are not necessarily tied to a known exploitable bug. These may be proactive or preventative measures. For instance, replacing a weaker encryption algorithm with a stronger one, adding additional validation on inputs, hardening configurations, or improving permission checks could all be categorized as security improvements. These changes reduce the likelihood of future vulnerabilities or make the system more secure by design. They might not be urgent, but they are beneficial for security-conscious deployments.
In simpler terms, security fixes involve plugging holes that were found, whereas security improvements involve strengthening the walls. Both are valuable, but they are handled differently in the support policy (particularly when it comes to backporting, as discussed below).
From an administrator's perspective, whenever a new release comes out, pay attention to the release notes on security. If it lists “Security fix,” you should aim to apply that update as soon as possible, especially if your version is affected. “Security improvements” are also good to have, but since they are not remediating an active vulnerability, they may not be backported to older versions – you’ll get them when you move to the new release.
Backporting policy (What gets backported and what doesn’t?)
Change type | Back‑ported? | Guiding principle | What you can expect |
|---|---|---|---|
Security fixes (vulnerabilities) | Always | Protect every deployment that is still within its support window. | A patch is released for all supported lines—including LTS—usually within days of the fix landing in the main branch. You never have to jump to a new major/minor just to stay secure. |
Critical bug fixes | Usually | Keep supported versions stable and usable. | The team evaluates impact and prevalence. If the bug affects production stability, a point‑release is issued for each affected supported version (e.g., 7.1.x and 7.2.x). |
General bug fixes & minor enhancements | No | Focus developer effort on forward progress. | Routine UI tweaks, performance tuning, or low‑risk refactors land only in the next scheduled minor or major release. To get them, plan an upgrade rather than waiting for a hot‑patch. |
Security improvements | No | Treat improvements as new features rather than emergency fixes. | They appear in the next release train (e.g., 7.3). Older lines remain unchanged unless an actual vulnerability is discovered. |
Practical implications for administrators
Running LTS? You’ll receive every security patch plus any critical‑stability fixes for nine months. No surprises, no feature churn.
Staying on a short‑term release? You’re covered for three months after the next version ships. After that, upgrade to keep getting fixes.
Need a bug addressed? If it isn’t security‑critical or severely destabilizing, the answer is “upgrade to the latest minor.” That’s where non‑urgent maintenance happens.
In short, Rocket.Chat backports what must be fixed to keep your instance safe and running; everything else moves forward so the platform can keep evolving.
This policy means that if you prefer not to upgrade frequently, using an LTS release is advantageous because you’ll receive security fixes for a longer period. However, even on LTS, you will not get non-security improvements until you move to a newer release. Conversely, those who track the latest releases will get improvements sooner, but must update more often and still need to stay within the 3-month support window to receive fixes.
Always consult Rocket.Chat’s official security advisories and announcements. In some cases (especially for critical vulnerabilities), Rocket.Chat might even provide out-of-band patches or workarounds. The Version Durability Matrix will list which versions are currently supported and receiving patches. Use that as authoritative guidance on where backports will apply. If your version is not on that list, it will not receive any fixes and an upgrade is required to maintain security.
End-of-Life (EOL) and implications
When a Rocket.Chat version’s support window expires (after 3 or 9 months, as applicable), that version reaches End-of-Life (EOL) status. Running an EOL version has important consequences that system administrators must heed:
No Official Updates or Fixes: Once EOL, the development team no longer provides patch releases for bugs or security vulnerabilities on that version. Any known issues will remain unresolved unless you upgrade to a supported version. This leaves EOL installations increasingly vulnerable over time.
Loss of Cloud Services Integration: Rocket.Chat has implemented policies to disable cloud-dependent services for EOL servers. Hosted services such as the Push Notification Gateway, Marketplace (app marketplace), and Omnichannel Citizen Engagement integrations will cease to function for that particular version once it is out of support end of life date.
Mobile and Desktop Apps Access: Similarly, official Rocket.Chat mobile and desktop clients will not connect to EOL servers. The mobile and desktop applications enforce version checks to ensure the server is within the supported range. If users attempt to use a modern Rocket.Chat mobile/desktop app against an outdated server, they may encounter errors or warnings preventing login. (In practice, the existing installed app may continue working with an out-of-support server until the app itself updates to a version that enforces the block. But administrators should assume that once the server is EOL, any update of the clients could cut off connectivity.)
Security and Compliance Risks: An unsupported version that no longer receives security patches is vulnerable. For organizations subject to security standards or data protection compliance, running an EOL version can be a liability. It’s generally considered best practice to upgrade before the EOL date to ensure continued security hardening and compliance.
Once your workspace release reaches End of Life (EOL) and exits the support window, access to the Mobile and Desktop apps will no longer be available for users.
End-of-life means the Rocket.Chat instance is effectively frozen in time and disconnected from the support ecosystem. For uninterrupted service administrators must keep the server within a supported release. Always plan upgrades before the EOL date to avoid any disruption.
Running unsupported (EOL) versions violates our support terms, voids any applicable warranties, and significantly increases the risk of compliance and security vulnerabilities.
Upgrade practices and recommendations
Keeping Rocket.Chat up to date is essential for stability and security. System administrators and IT decision-makers should establish a regular upgrade process. Below are recommended best practices for planning and executing Rocket.Chat upgrades:
Track releases and schedule updates: Monitor Rocket.Chat release announcements (via the official release notes and blog) and know the support timelines of your deployment’s version. Keep a calendar or reminders for when your version will hit EOL. A good practice is to plan at least one upgrade within each 6-month period (or according to LTS cadence if you adopt LTS versions). This proactive approach ensures you never fall out of support.
Review release notes: Before upgrading, read the release notes for the target version (and any interim versions if you skipped some). Pay special attention to sections on Breaking Changes, New Features, Deprecations, and Security Fixes. Release notes will mention if any manual steps are needed (for example, database migrations, reindexing, changes to configuration files, or removal of deprecated settings). Understanding what’s new or changed helps in assessing the impact on your environment.
Backup your data: Always perform a full backup of your Rocket.Chat instance prior to any upgrade. This includes the MongoDB database, uploaded files/attachments, and any custom configuration or scripts. A current backup ensures that you can restore the previous state if something goes wrong. Verify your backups are valid and accessible.
Test in a staging environment: If possible, set up a staging or test instance of Rocket.Chat that mirrors your production environment (use a copy of your database, if feasible, and similar configuration). Perform the upgrade on the staging instance first. This allows you to catch potential issues (like compatibility problems with custom integrations, apps from the marketplace, or performance changes) in a controlled setting. For example, if you use webhooks or bots, ensure they still function after the upgrade in the test environment.
Verify client and dependency compatibility: Check the system requirements for the new version. Major releases may require updated dependencies (e.g., a newer MongoDB version or Node.js runtime). Ensure your infrastructure meets these requirements ahead of time. Also, verify that your users’ web browsers or the desktop/mobile apps are compatible with the new server version. (Rocket.Chat usually maintains backward compatibility with recent app versions, but if you lag very far behind, clients might auto-update and expect a newer server API.)
Schedule downtime or maintenance window: For production upgrades, perform the update during a planned maintenance window when user activity is low. Notify end-users in advance about the expected downtime. This helps prevent surprises and gives you uninterrupted time to perform the upgrade and initial post-upgrade checks.
Execute the upgrade: Follow the official upgrade guides for your installation method (Docker, Podman, Snap, manual, etc.). It often involves steps like downloading the new release, installing dependencies, migrating the database (if the release notes indicate), and restarting the Rocket.Chat service on the new version. Monitor the upgrade process closely for any error messages.
Post-upgrade testing: After upgrading, do a sanity check on core functionalities. Have a checklist: users can log in, send messages, upload files, notifications work, any critical integrations (LDAP, OAuth, etc.) authenticate properly, and so on. Also, ensure that background jobs (like push notifications) are operating. Check the server logs for any warnings or errors that might indicate issues to address.
Rollout to users and follow up: Once you’re satisfied that the new version is running well, inform users that the system is updated. Encourage users to update their Rocket.Chat client apps to the latest version to ensure optimal compatibility. Keep an eye on performance and user feedback in the days following the upgrade. If any unexpected bug appears, you may need to report it upstream or look for a patch release that fixes it.
Maintain regular cadence: Make upgrades a routine part of system maintenance. This prevents the scenario of having to jump multiple versions in one go (which can be more complex). By staying within supported versions, you ensure access to support and avoid the disruptions associated with EOL (as discussed above).
By following these practices – monitoring releases, planning ahead for EOL, testing, and then upgrading in a controlled manner – administrators can significantly reduce the risk of downtime or incompatibilities. Well-planned upgrades keep Rocket.Chat securely, performantly, and equipped with the latest features that benefit your organization.
By understanding the release cycle – including the types of releases, how long support lasts for each, what each contains, and how to plan upgrades – system administrators can make informed decisions about when and how to update Rocket.Chat. Rocket.Chat’s Long-Term Support options provide flexibility for those who need a slower pace, while regular releases ensure the platform continues to evolve. Staying within the support lifecycle, applying security patches, and following best practices for upgrades will help you get the most out of Rocket.Chat in a stable and secure manner
Additional resources:
Monitor the releases through the Rocket.Chat GitHub releases page. The Version Durability document lists the releases and the end-of-life for each release.
The detailed release notes help you understand the latest improvements so you can determine processes for your workspace updates based on your organization's needs.
Check out the Support Center for details on Rocket.Chat’s support services.
The Support Prerequisites document helps you understand the requirements your workspaces must meet to receive and maintain support from our team.