This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.
Release Management
Understanding Fusion SMB's release cycle and support policy is essential for advising customers on upgrades and ensuring they run supported versions. This page covers version numbering, release types, and the support lifecycle.
Version Numbering
Fusion SMB uses the version format X.Y.Z:
| Component | Meaning | Example |
|---|---|---|
| X | Release year + 1000 | 3025 = year 2025 |
| Y | Stable release month | 10 = October, 4 = April |
| Z | Maintenance release number | 0 = initial, 1 = first maintenance |
Example: Version 3025.10.1 is the first maintenance release of the October 2025 stable line.
Release Types
Major Releases
Major releases introduce new features and improvements. They are published twice per year, targeting:
- Q2 — end of April (±~2 weeks)
- Q4 — end of October (±~2 weeks)
These are referred to by their quarter: 25Q4, 26Q2, etc.
Maintenance Releases
Maintenance releases deliver bug fixes only on top of an existing stable line. They are issued every 2–3 months for each active stable line and include:
- Crash fixes
- Behavioral bug corrections
- Interoperability issues
A maintenance release may be skipped if no qualifying bugs have been identified. The maintenance process is reviewed every two months regardless.
Hotfix Releases
Hotfix releases address zero-day vulnerabilities and other high-profile, high-severity issues that cannot wait for the regular maintenance cycle. Like a maintenance release, a hotfix contains only bug, crash, and interoperability fixes — never new features.
The difference is timing: a hotfix is issued as soon as the fix is validated, rather than on the usual 2–3 month maintenance cadence. It follows the same release, signing, and verification process as a normal maintenance release; only the schedule is accelerated.
Hotfixes are delivered to every currently supported line under the n-2 support policy.
Support Policy: n-2 Rule
Fusion SMB follows an n-2 support policy: the three most recently released stable lines are simultaneously supported. Each supported stable line receives ongoing maintenance releases.
When a new major release becomes available, the oldest of the three supported lines moves to End of Life.
The n-2 rule is the governing criterion. If an earlier time-based guideline (such as an 18-month window) conflicts with the n-2 count, the n-2 count takes precedence.
Currently Supported Versions
| Version | Type | Release Date | Status |
|---|---|---|---|
| 3026.4.1 | Maintenance | 2026-08-07 | Latest stable |
| 3026.4.0 | Major | 2026-05-22 | Supported |
| 3025.10.1 | Maintenance | 2026-03-06 | Supported |
| 3025.10.0 | Major | 2025-11-10 | Supported |
| 3025.4.1 | Maintenance | 2025-05-28 | Supported |
| 3025.4.0 | Major | 2025-05-23 | Supported |
Upcoming
3026.10.0 is planned for Q4 2026. When it becomes available, 3025.4.x will move to End of Life.
End of Life Versions
| Version | Type | Release Date | Status |
|---|---|---|---|
| 3024.10.1 | Maintenance | 2025-02-20 | End of Life |
| 3024.10.0 | Major | 2024-11-08 | End of Life |
| 3024.3.22 | Major | 2024-03-26 | End of Life |
Versions that have reached End of Life no longer receive maintenance releases and are not eligible for official support cases.
Support Guidance for Partners
When a Customer Runs an EOL Version
- Inform the customer that their version is no longer supported and does not receive security or bug fixes.
- Recommend upgrading to the latest supported stable release (currently 3026.4.1, released 2026-08-07).
- Offer assistance — Tuxera's Enterprise support team can help with upgrade planning. Direct them to Contacting Support.
When a Customer Asks About Upgrade Timing
- Maintenance releases are safe to apply — they contain only bug fixes with no feature changes.
- Hotfix releases should be applied promptly when issued — they exist because the underlying issue (typically a zero-day vulnerability) is too severe to wait for the next maintenance window. Scope is bug-fix-only, so the upgrade risk profile matches a maintenance release.
- Major releases should be tested in a non-production environment first, especially if the customer uses advanced features (clustering, audit logging, custom ACL mappings).
- Skipping versions is supported — customers can upgrade directly from any version to the latest stable release. Refer to the upgrade documentation for guidance on migrating between major versions.
Clusters must be upgraded to 3025.4.1 before upgrading any further. If a customer's cluster is on any version prior to 3025.4.1, that upgrade must happen first — a direct jump to the latest release is not supported for clusters. Node ordering and ca_path handling also matter during the rolling upgrade; see Common Issues before advising a clustered customer.
Version Checks During Support Cases
Always verify the customer's version early in the support process:
tsmb-server -v
If the version is EOL, note this in the support case. While Tuxera may still provide guidance, the recommended path is an upgrade to a supported version before deep troubleshooting.
Release Cadence Summary
| Quarter | Event |
|---|---|
| Q1 (Jan–Mar) | Maintenance releases for active stable lines |
| Q2 (Apr) | Major release + oldest stable line moves to EOL |
| Q3 (Jul–Sep) | Maintenance releases for active stable lines |
| Q4 (Oct) | Major release + oldest stable line moves to EOL |
Reference: For the complete version history and lifecycle details, see Version Lifecycle & Support Policy on docs.tuxera.com.
3026.4.1 shipped on 2026-08-07 but the published version-lifecycle page still shows 3026.4.0 as latest stable. If a customer quotes docs.tuxera.com back at you, that is why. The table above reflects what has actually been released.