Important Upgrade Notes#
Available on all plans
self-hosted deployments
Important
Support for Mattermost Server v9.5 Extended Support Release has come to the end of its life cycle on November 15, 2024. Upgrading to Mattermost Server v9.11 or later is required.
MySQL 8.0.22 contains an issue with JSON column types changing string values to integers which is preventing Mattermost from working properly. Users are advised to avoid this database version.
Upgrading the Microsoft Teams Calling plugin to v2.0.0 requires users to reconnect their accounts.
When upgrading to 7.x from a 5.x release please make sure to upgrade to 5.37.10 first for the upgrade to complete successfully.
Mattermost plugins built with Go versions 1.22.0 and 1.22.1 do not work. Plugin developers should use go 1.22.2 or newer instead.
Keybase has stopped serving our Ubuntu repository signing key. If you were using it, update your installation scripts to retrieve the key as mentioned in our docs: https://docs.mattermost.com/install/install-ubuntu.html.
If you’re upgrading from a version earlier than… |
Then… |
|
---|---|---|
v10.3 |
The Classic Mobile App has been phased out. Please download the new v2 Mobile App from the Apple App Store or Google Play Store. See more details in the classic mobile app deprecation Mattermost forum post. |
|
v10.2 |
Docker Content Trust (DCT) for signing Docker image artifacts has been replaced by Sigstore Cosign in v10.2 (November, 2024). If you rely on artifact verification using DCT, please transition to using Cosign. See the upcoming DCT deprecation Mattermost forum post for more details. |
|
v10.0 |
We no longer support new installations using MySQL starting in v10. All new customers and/or deployments will only be supported with the minimum supported version of the PostgreSQL database. End of support for MySQL is targeted for Mattermost v11. |
|
Apps Framework is deprecated for new installs. Please extend Mattermost using webhooks, slash commands, OAuth2 apps, and plugins. |
||
Mattermost v10 introduces Playbooks v2 for all Enterprise licensed customers. Professional SKU customers may continue to use Playbooks v1 uninterrupted which will be maintained and supported until September 2025, followed by an appropriate grandfathering strategy. More detailed information and the discussion are available on our forums here. |
||
Renamed |
||
Renamed announcement banner feature to “system-wide notifications”. |
||
Renamed “Collapsed Reply Threads” to “Threaded Discussions” in the System Console. |
||
Renamed “System Roles” to “Delegated Granular Administration” in the System Console. |
||
Renamed “Office 365” to “Entra ID” for SSO logins. |
||
Fully deprecated the |
||
Pre-packaged Calls plugin v1.0.1. This includes breaking changes including the removal of group calls from unlicensed servers in order to focus supportability and quality on licensed servers. Unlicensed servers can continue to use Calls in direct message channels, which represent the majority of activity. |
||
Removed deprecated |
||
Removed deprecated |
||
Deprecated the experimental Strict CSRF token enforcement. This feature will be fully removed in Mattermost v11. |
||
v9.11 |
Added support for Elasticsearch v8. Also added Beta support for Opensearch v1.x and v2.x. A new config setting Note
If you are using Elasticsearch v8, be sure to set |
|
v9.5 |
We have stopped supporting MySQL v5.7 since it’s at the end of life. We urge customers to upgrade their MySQL instance at their earliest convenience. |
|
Added safety limit error message in compiled Team Edition and Enterprise Edition deployments when enterprise scale and access control automation features are unavailable and count of users who are registered and not deactivated exceeds 10,000. ERROR_SAFETY_LIMITS_EXCEEDED. |
||
v9.2 |
Fixed data retention policies to run jobs when any custom retention policy is enabled even when the global retention policy is set to “keep-forever”. Before this fix, the enabled custom data retention policies wouldn’t run as long as the global data retention policy was set to “keep-forever” or was disabled. After the fix, the custom data retention policies will run automatically even when the global data retention policy is set to “keep-forever”. Once the server is upgraded, posts may unintentionally be deleted. Admins should make sure to disable all custom data retention policies before upgrading, and then re-enable them again after upgrading. |
|
v9.1 |
In v9.1.0, improved performance on data retention New migration for a new table: MySQL: CREATE TABLE
IF NOT EXISTS
RetentionIdsForDeletion(Id
VARCHAR(26) NOT NULL,
TableName VARCHAR(64),
Ids json, PRIMARY KEY (Id
), KEY
idx_retentionidsfordeletion_tablename
(TableName)) ENGINE =
InnoDB DEFAULT CHARSET =
utf8mb4;
``
PostgreSQL: CREATE TABLE
IF NOT EXISTS
retentionidsfordeletion(id
VARCHAR(26) PRIMARY KEY,
tablename VARCHAR(64),
ids VARCHAR(26) []);
CREATE INDEX
IF NOT EXISTS
idx_retentionidsfordeletion_tablename
ON retentionidsfordeletion(
tablename);
``
Hard deleting a user or a channel will now also clean up associated reactions. Removed feature flag Added a new configuration setting |
|
Minimum supported Desktop App version is now v5.3. OAuth/SAML flows were modified to include |
||
v9.0 |
Removed the deprecated Insights feature. |
|
Mattermost Boards and various other plugins have transitioned to being fully community supported. See this forum post for more details. |
||
The |
||
v8.1 |
In v8.1.2, improved performance on data retention New migration for a new table: MySQL: CREATE TABLE
IF NOT EXISTS
RetentionIdsForDeletion(Id
VARCHAR(26) NOT NULL,
TableName VARCHAR(64),
Ids json, PRIMARY KEY (Id
), KEY
idx_retentionidsfordeletion_tablename
(TableName)) ENGINE =
InnoDB DEFAULT CHARSET =
utf8mb4;
``
PostgreSQL: CREATE TABLE
IF NOT EXISTS
retentionidsfordeletion(id
VARCHAR(26) PRIMARY KEY,
tablename VARCHAR(64),
ids VARCHAR(26) []);
CREATE INDEX
IF NOT EXISTS
idx_retentionidsfordeletion_tablename
ON retentionidsfordeletion(
tablename);
``
Hard deleting a user or a channel will now also clean up associated reactions. Removed feature flag Added a new configuration setting |
|
v8.0 |
Insights has been deprecated for all new instances and for existing servers that upgrade to v8.0. See more details in this forum post on why Insights has been deprecated. |
|
The Focalboard plugin is now disabled by default for all new instances and can be enabled in the System Console > Plugin settings. |
||
The Channel Export and Apps plugins are now disabled by default. |
||
Apps Bar is now enabled by default for on-prem servers. |
||
In the main server package, the Go module path has changed from |
||
Introduced the public submodule, housing the familiar model and plugin packages, but now discretely versioned from the server. It is no longer necessary to go get a particular commit hash, as Go programs and plugins can now opt-in to importing github.com/mattermost/mattermost-server/server/public and managing versions idiomatically. While this submodule has not yet shipped a v1 and will introduce breaking changes before stabilizing the API, it remains both forwards and backwards compatible with the Mattermost server itself. |
||
As part of the public submodule above, a |
||
Removed support for PostgreSQL v10. The new minimum PostgreSQL version is now v11. |
||
The Mattermost public API for Go is now available as a distinctly versioned package. Instead of pinning a particular commit hash, use idiomatic Go to add this package as a dependency: go get github.com/mattermost/mattermost-server/server/public. This relocated Go API maintains backwards compatibility with Mattermost v7. Furthermore, the existing Go API previously at github.com/mattermost/mattermost-server/v6/model remains forward compatible with Mattermost v8, but may not contain newer features. Plugins do not need to be recompiled, but developers may opt in to using the new package to simplify their build process. The new public package is shipping alongside Mattermost v8 as version 0.5.0 to allow for some additional code refactoring before releasing as v1 later this year. |
||
Three configuration fields have been added, |
||
The Go MySQL driver has changed the |
||
Removed
|
||
Removed deprecated |
||
Removed deprecated |
||
For servers wanting to allow websockets to connect from origins other than the origin of the site URL, please set the |
||
In v8.0 release, the following repositories are merged into one: |
||
Fixed an issue caused by a migration in the previous release. Query takes around 11ms on a PostgreSQL 14 DB t3.medium RDS instance. Locks on the preferences table will only be acquired if there are rows to delete, but the time taken is negligible. |
||
Fixed an issue where a user would still see threads in the threads view of channels they have left. Migration execution time in PostgreSQL: Execution time: 58.11 sec, DELETE 2766690. Migration execution time in MySQL: Query OK, 2766769 rows affected (4 min 47.57 sec). |
||
For servers wanting to allow websockets to connect from other origins, please set the |
||
The file info stats query is now optimized by denormalizing the On a PostgreSQL 12.14 DB with 1731 rows in FileInfo and 11M posts, it took around 0.27s On a MySQL 8.0.31 DB with 1405 rows in FileInfo and 11M posts, it took around 0.3s |
||
v7.10 |
In v7.10.1, fixed an issue caused by a migration in the previous release. Query takes around 11ms on a PostgreSQL 14 DB t3.medium RDS instance. Locks on the preferences table will only be acquired if there are rows to delete, but the time taken is negligible. |
|
In v7.10.1, fixed an issue where a user would still see threads in the threads view of channels they have left. Migration execution time in MySQL: Query OK, 2766769 rows affected (4 min 47.57 sec). Migration execution time in PostgreSQL: 58.11 sec, DELETE 2766690. |
||
In v7.10.3, for servers wanting to allow websockets to connect from origins other than the origin of the site URL, please set the
|
||
v7.9 |
Added a new index on
|
|
In v7.9.4, fixed an issue where a user would still see threads in the threads view of channels they have left. Migration execution time in MySQL: Query OK, 2766769 rows affected (4 min 47.57 sec). Migration execution time in PostgreSQL: 58.11 sec, DELETE 2766690. |
||
In v7.9.4, backported a fix related Oauth 2. Query times depend on if you have rows to delete or not. With no rows to delete:
4 rows:
Those times are based off the following table sizes:
You can assess the number of impacted rows by running the following: PostgreSQL: SELECT count(o.*)
FROM oauthaccessdata o
WHERE NOT EXISTS (
SELECT p.*
FROM preferences p
WHERE o.clientid = p.name
AND o.userid = p.
userid
AND p.category =
'oauth_app'
);
MySQL: SELECT COUNT(o.`Token`)
FROM OAuthAccessData o
LEFT JOIN Preferences p ON o.
clientid = p.name
AND o.userid = p.userid
AND p.category = 'oauth_app'
INNER JOIN Sessions s ON o.token = s
.token
WHERE p.name IS NULL;
Locks on the |
||
In v7.9.5, for servers wanting to allow websockets to connect from origins other than the origin of the site URL, please set the
|
||
v7.8 |
Message Priority & Acknowledgement is now enabled by default
for all instances. You may disable this feature in the System Console by going to Posts > Message Priority or via the config |
|
In v7.8.5, fixed an issue where a user would still see threads in the threads view of channels they have left. Migration execution time in MySQL: Query OK, 2766769 rows affected (4 min 47.57 sec). Migration execution time in PostgreSQL: 58.11 sec, DELETE 2766690. |
||
In v7.8.5, backported a fix related Oauth 2. Query times depend on if you have rows to delete or not. With no rows to delete:
4 rows:
Those times are based off the following table sizes:
You can assess the number of impacted rows by running the following: PostgreSQL: SELECT count(o.*)
FROM oauthaccessdata o
WHERE NOT EXISTS (
SELECT p.*
FROM preferences p
WHERE o.clientid = p.name
AND o.userid = p.
userid
AND p.category =
'oauth_app'
);
MySQL: SELECT COUNT(o.`Token`)
FROM OAuthAccessData o
LEFT JOIN Preferences p ON o.
clientid = p.name
AND o.userid = p.userid
AND p.category = 'oauth_app'
INNER JOIN Sessions s ON o.token = s
.token
WHERE p.name IS NULL;
Locks on the |
||
In v7.8.7, for servers wanting to allow websockets to connect from origins other than the origin of the site URL, please set the
|
||
In v7.8.11, improved performance on data retention New migration for a new table: MySQL: CREATE TABLE
IF NOT EXISTS
RetentionIdsForDeletion(Id
VARCHAR(26) NOT NULL,
TableName VARCHAR(64),
Ids json, PRIMARY KEY (Id
), KEY
idx_retentionidsfordeletion_tablename
(TableName)) ENGINE =
InnoDB DEFAULT CHARSET =
utf8mb4;
``
PostgreSQL: CREATE TABLE
IF NOT EXISTS
retentionidsfordeletion(id
VARCHAR(26) PRIMARY KEY,
tablename VARCHAR(64),
ids VARCHAR(26) []);
CREATE INDEX
IF NOT EXISTS
idx_retentionidsfordeletion_tablename
ON retentionidsfordeletion(
tablename);
``
Hard deleting a user or a channel will now also clean up associated reactions. Removed feature flag Added a new configuration setting |
||
v7.7 |
Plugins with a webapp component may need to be updated to work with Mattermost v7.7 release and the updated This is to avoid plugins crashing with an error about |
|
Denormalized Test results for schema changes are outlined below: instance: size of number of posts: 12 million number of reactions: 2.5 million MySQL: -- Drop any existing TeamId column from 000094_threads_teamid.up.sql
SET @preparedStatement = (SELECT IF(
EXISTS(``
SELECT 1 FROM INFORMATION_SCHEMA.STATISTICS
WHERE table_name = 'Threads'
AND table_schema = DATABASE()
AND column_name = 'TeamId'
),
'ALTER TABLE Threads DROP COLUMN TeamId;',
'SELECT 1;'
));
PREPARE removeColumnIfExists FROM @preparedStatement;
EXECUTE removeColumnIfExists;
DEALLOCATE PREPARE removeColumnIfExists;
SET @preparedStatement = (SELECT IF(
NOT EXISTS(
SELECT 1 FROM INFORMATION_SCHEMA.COLUMNS
WHERE table_name = 'Threads'
AND table_schema = DATABASE()
AND column_name = 'ThreadTeamId'
),
'ALTER TABLE Threads ADD COLUMN ThreadTeamId varchar(26) DEFAULT NULL;',
'SELECT 1;'
));
PREPARE addColumnIfNotExists FROM @preparedStatement;
EXECUTE addColumnIfNotExists;
DEALLOCATE PREPARE addColumnIfNotExists;
Query OK, 0 rows affected (7.71 sec)
UPDATE Threads, Channels
SET Threads.ThreadTeamId = Channels.TeamId
WHERE Channels.Id = Threads.ChannelId
AND Threads.ThreadTeamId IS NULL;
Query OK, 846313 rows affected (51.32 sec)
Rows matched: 846313 Changed: 846313 Warnings: 0
PostgreSQL: -- Drop any existing TeamId column from 000094_threads_teamid.up.sql
ALTER TABLE threads DROP COLUMN IF EXISTS teamid;
ALTER TABLE threads ADD COLUMN IF NOT EXISTS threadteamid VARCHAR(26);
ALTER TABLE
Time: 2.236 ms
UPDATE threads
SET threadteamid = channels.
teamid
FROM channels
WHERE threads.threadteamid IS
NULL
AND channels.id = threads.
channelid;
UPDATE 847646
Time: 29744.608 ms (00:29.745)
**Backwards-compatibility:**
A previous version of Mattermost can run with the new schema changes
**Table locks or impact to existing operations on the table:**
Table locks - Threads table
Queries posted above can be run prior to upgrading Mattermost for both MySQL and PostgreSQL. After schema changes migration becomes instantaneous (0.78 sec). |
||
Starting with the Calls version shipping with v7.7, there’s now a minimum version requirement when using the external RTCD service. This means that if Calls is configured to use the external service, customers need to upgrade RTCD first to at least version 0.8.0 or the plugin will fail to start. |
||
In v7.7.2, Message Priority & Acknowledgement is now enabled by
default for all instances. You may disable this feature in the System Console by going to Posts > Message Priority or via the config |
||
v7.5 |
Added a new schema migration to ensure |
|
For |
||
v7.3 |
Boards is moving from a channel-based to a role-based permissions system. The migration will happen automatically, but your administrator should perform a backup prior to the upgrade. We removed workspaces, so if you were a member of many boards prior to migration, they will now all appear under the same sidebar. |
|
v7.2 |
Several schema changes impose additional database constraints to make the data more strict. All the commands listed below were tested on a 8 core, 16GB RAM machine. Here are the times recorded: PostgreSQL (131869 channels, 2 teams):
MySQL (270959 channels, 2 teams):
|
|
v7.1 |
A new configuration option |
|
Mattermost v7.1 introduces schema changes in the form of a new column and its index. Our test results for the schema changes are included below:
You can run the following SQL queries before the upgrade to obtain a lock on MySQL:
PostgreSQL:
|
||
v7.0 |
IMPORTANT: Session length configuration settings have changed from using a unit of days to hours. Instances using a config.json file or a database configuration for the following values should be automatically migrated to the new units, but instances using environment variables must make the following changes:
|
|
MySQL self-hosted customers may notice the migration taking longer than usual when having a large number of rows in FileInfo table. For MySQL, it takes around
19 seconds for a table of size 700,000 rows. The time required for PostgreSQL is negligible. The testing was performed on a machine with specifications of
|
||
When a new configuration setting via System Console > Experimental > Features > Enable App Bar is enabled, all channel header icons registered by plugins
will be moved to the new Apps Bar, even if they do not explicitly use the new registry function to render a component there. The setting for Apps Bar defaults
to |
||
The value of |
||
Collapsed Reply Threads is now generally available and enabled by default for new Mattermost servers. For servers upgrading to v7.0 and later, please reference this article for more information and guidance on enabling the feature. |
||
v6.7 |
New schema changes were introduced in the form of a new index. The following summarizes the test results measuring how long it took for the database queries to run with these schema changes: MySQL 7M Posts - ~17s (Instance: db.r5.xlarge) MySQL 9M Posts - 2min 12s (Instance: db.r5.large) Postgres 7M Posts - ~9s (Instance: db.r5.xlarge) For customers wanting a zero downtime upgrade, they are encouraged to apply this index prior to doing the upgrade. This is fully backwards compatible and will not acquire any table lock or affect any existing operations on the table when run manually. Else, the queries will run during the upgrade process and will lock the table in non-MySQL environments. Run the following to apply this index: For MySQL: For Postgres: |
|
In v6.7.1, the value of |
||
v6.6 |
The Apps Framework protocol for binding/form submissions has changed, by separating the single call into separate submit, form, refresh and lookup calls. If any users have created their own Apps, they have to be updated to the new system. |
|
Channel admins can now configure certain actions to be executed automatically based on trigger conditions without writing any code. Users running an older Playbooks release need to upgrade their Playbooks instance to at least v1.26 to take advantage of the channel actions functionality. |
||
In v6.6.2, the value of |
||
v6.5 |
The |
|
In v6.5.2, the value of |
||
v6.4 |
A new schema migration system has been introduced, so we strongly recommend backing up the database before updating the server to this version. The new
migration system will run through all existing migrations to record them to a new table. This will only happen for the first run in order to migrate the
application to the new system. The table where the migration information is stored is called On MySQL, if you encounter an error “Failed to apply database migrations” when upgrading to v6.4.0, it means that there is a mismatch between the
table collation and the default database collation. You can manually fix this by changing the database collation with
It has been commonly observed on MySQL 8+ systems to have an error |
|
The new migration system requires the MySQL database user to have additional EXECUTE, CREATE ROUTINE, ALTER ROUTINE and REFERENCES privileges to run schema migrations. |
||
v6.3 |
In v6.3.3, the default for |
|
In v6.3.9, the value of |
||
v6.2 |
Channel results in the channel autocomplete will include private channels. Customers using Bleve or Elasticsearch for autocomplete will have to reindex their data to get the new results. Since this can take a long time, we suggest disabling autocomplete and running indexing in the background. When this is complete, re-enable autocomplete. Note Only channel members see private channel names in autocomplete results. |
|
In v6.2.3, the default for |
||
Mattermost Boards requires |
||
v6.1 |
Please refer to the schema migration analysis when upgrading to v6.1. |
|
The Bleve index has been updated to use the scorch index type. This new default index type features some efficiency improvements which means that the indexes use significantly less disk space. To use this new type of index, after upgrading the server version, run a purge operation and then a reindex from the Bleve section of the System Console. Bleve is still compatible with the old indexes, so the currently indexed data will work fine if the purge and reindex is not run. |
||
A composite index has been added to the jobs table for better query performance. For some customers with a large jobs table, this can take a long time, so we recommend adding the index during off-hours, and then running the migration. A table with more than 1 million rows can be considered as large enough to be updated prior to the upgrade.
|
||
In v6.1.3, the default for |
||
Mattermost Boards requires |
||
v6.0 |
Longer migration times can be expected.
The field type of Data in 1. Low effort, long downtime - This is the usual process of starting a v6 server normally. This has two implications: during the migration process, various tables will be locked which will render those tables read-only during that period. Secondly, once the server finishes migration and starts the application, no other v5 server can run in the cluster. 2. Medium effort, medium downtime - This process will require SQL queries to be executed manually on the server. To avoid causing a table lock, a customer can choose to use the pt-online-schema-change tool for MySQL. For Postgres, the table locking is very minimal. The advantage is that since there are a lot of queries, the customer can take their own time to run individual queries during off-hours. All queries except #11 are safe to be executed this way. Then the usual method of (1) can be followed. 3. High effort, low downtime - This process requires everything of (2), plus it tries to minimize the impact of query #11. We can do this by following step 2, and then starting v6 along with a running v5 server, and then monitor the application logs. As soon as the v6 application starts up, we need to bring down a v5 node. This minimizes the downtime to only a few seconds. It is recommended to start Mattermost directly and not through systemctl to avoid the server process getting killed during the migration. This can happen since
the value of Customers using the Mattermost Kubernetes operator should be aware of the above migration information and choose the path that is most appropriate for them. If (1) is acceptable, then the normal upgrade process using the operator will suffice. For minimum downtime, follow (2) before using the operator to update Mattermost following the normal upgrade process. |
|
While trying to upgrade to a Mattermost version >= 6.0.x, you might encounter the following error: This means that the particular column has some invalid JSON values which need to be fixed manually. A common fix that is known to work is to wipe out all
Please follow these steps:
Then try to start Mattermost again. |
||
Please see unsupported legacy releases documentation for a list of deprecations in this release. |
||
Focalboard plugin has been renamed to Mattermost Boards, and v0.9.1 (released with Mattermost v6.0) is now enabled by default. |
||
The advanced logging configuration schema changed. This is a breaking change relative to 5.x. See updated documentation. |
||
The existing theme names and colors, including “Mattermost”, “Organization”, “Mattermost Dark”, and “Windows Dark” have been updated to the new “Denim”, “Quartz”, “Indigo”, and “Onyx” theme names and colors, respectively. Anyone using the existing themes will see slightly modified theme colors after their server or workspace is upgraded. The theme variables for the existing “Mattermost”, “Organization”, “Mattermost Dark”, and “Windows Dark” themes will still be accessible in our documentation, so a custom theme can be created with these theme variables if desired. Custom themes are unaffected by this change. |
||
Some breaking changes to plugins are included:
|
||
Mattermost Boards requires |
||
v5.38.0 |
The “config watcher” (the mechanism that automatically reloads the |
|
v5.38 adds fixes for some of the incorrect mention counts and unreads around threads and channels since the introduction of Collapsed Reply Threads (Beta). This
fix is done through a SQL migration, and it may take several minutes to complete for large databases. The |
||
Focalboard v0.8.2 (released with Mattermost v5.38.0) requires Mattermost v5.37+ due to the new database connection system. |
||
v5.37.0 |
The |
|
Collapsed Reply Threads are available as Beta in Mattermost Server v5.37 and later. It’s expected that you may experience bugs as we stabilize the feature. In particular, please be aware of the known issues documented here. |
||
v5.37 adds support for emoji standard v13.0. If you have added a custom emoji in the past that uses one of the new system names, then it is going to get overwritten by the system emoji. The workaround is to change the custom emoji name. |
||
Parts of Incident Collaboration are now available to all Mattermost editions. As part of this update, Incident Collaboration will require a minimum server version of v5.37. To learn more about what is available in each edition, visit our pricing page. |
||
In v5.37.8, the default for |
||
v5.36.0 |
Gossip clustering mode is now in General Availability and is no longer available as an option. All cluster traffic will always use the gossip protocol. The
config setting Note For High Availability upgrades, all nodes in the cluster must use a single protocol. If an existing system is not currently using gossip, one node in a cluster can’t be upgraded while other nodes in the cluster use an older version. Customers must either use gossip for their High Availability upgrade, or customers must shut down all nodes, perform the upgrade, and then bring all nodes back up. |
|
To enable Focalboard, open the Marketplace from the sidebar menu, install the Focalboard plugin, then click on Configure, enable it, and save. Update your NGINX or Apache web proxy config. |
||
v5.35.0 |
Due to the introduction of backend database architecture required for upcoming new features, Shared Channels and Collapsed Reply Threads, the performance of the migration process for the v5.35 release (May 16, 2021) has been noticeably affected. Depending on the size, type, and version of the database, longer than usual upgrade times should be expected. This can vary from a couple of minutes (average case) to hours (worst case, MySQL 5.x only). A moderate to significant spike in database CPU usage should also be expected during this process. More details on the performance impact of the migration and possible mitigation strategies are available. |
|
The existing password generation logic used during the bulk user import process was comparatively weak. Hence it’s advised for admins to immediately reset the passwords for all the users who were generated during the bulk import process and whose password has not been changed even once. |
||
v5.35.0 introduces a new feature to search for files. Search results for files shared in the past may be incomplete until a content extraction command is executed to extract and index the content of files already in the database. Instances running Elasticsearch or Bleve search backends will also need to execute a Bulk Indexing after the content extraction is complete. Please see more details in this blog post. |
||
v5.34.1 |
v5.34.1 fixes an issue where upgrading to v5.34.0 runs a migration that can cause timeouts on MySQL installations. Upgrading to v5.34.1 may also execute missing migrations that were scheduled for v5.32.0. These additions can be lengthy on very big MySQL (version 5.x) installations.
|
|
v5.33.0 |
Deleting a reaction is now a soft delete in the |
|
WebSocket handshakes done with HTTP version lower than 1.1 will result in a warning, and the server will transparently upgrade the version to 1.1 to comply with
the WebSocket RFC. This is done to work around incorrect Nginx (and other proxy) configs that do not set the |
||
v5.32.0 |
|
|
Breaking changes to the Golang client API were introduced: |
||
A breaking change was introduced when upgrading the Go version to v1.15.5 where user logins fail with AD/LDAP Sync when the certificate of the LDAP Server has no Subject Alternative Name (SAN) in it. Creating a new certificate on the AD/LDAP Server with the SAN inside fixes this. |
||
TLS versions 1.0 and 1.1 have been deprecated by browser vendors. Starting in Mattermost Server v5.32 (February 16), mmctl returns an error when connected to Mattermost servers deployed with these TLS versions. System admins will need to explicitly add a flag in their commands to continue to use them. We recommend upgrading to TLS version 1.2 or higher. |
||
v5.31.0 |
For Mobile Apps v1.42.0+, the minimum server version is set to 5.31.3 as 5.31.3 fixed an issue where the server version was reported as v5.30.0. |
|
v5.29.0 |
A new configuration setting |
|
Disabled the xmlsec1-based SAML library in favor of the re-enabled and improved SAML library. |
||
v5.28.0 |
Now when the service crashes, it will generate a coredump instead of just dumping the stack trace to the console. This allows us to preserve the full information of the crash to help with debugging it. For more information about coredumps, please see: https://man7.org/linux/man-pages/man5/core.5.html. |
|
In-product notices have been introduced to keep system admins and end users informed of the latest product enhancements available in new server and desktop versions. Learn more about in-product notices and how to disable them in our documentation. |
||
Disabled the xmlsec1-based SAML library in favor of the re-enabled and improved SAML library. |
||
v5.27.0 |
Disabled the xmlsec1-based SAML library in favor of the re-enabled and improved SAML library. |
|
v5.26.0 |
In v5.26, Elasticsearch indexes needed to be recreated. Admins should re-index Elasticsearch using the Purge index and then Index now button so that all the changes will be included in the index. Systems may be left with a limited search during the indexing, so it should be done during a time when there is little to no activity because it may take several hours. |
|
An To update the key, one can execute:
For any change in this config setting to take effect, the whole cluster must be shut down first. Then the config change made, and then restarted. In a cluster, all servers either will completely use encryption or not. There cannot be any partial usage. |
||
SAML Setting “Use Improved SAML Library (Beta)” was forcefully disabled. |
||
PostgreSQL ended long-term support for version 9.4 in February 2020. From v5.26 Mattermost officially supports PostgreSQL version 10 as PostgreSQL 9.4 is no longer supported. New installs will require PostgreSQL 10+. Previous Mattermost versions, including our current ESR, will continue to be compatible with PostgreSQL 9.4. PostgreSQL 9.4 and all 9.x versions are now fully deprecated in our v5.30 release (December 16, 2020). Follow the Upgrading Section within the PostgreSQL documentation. |
||
v5.25.0 |
Some incorrect instructions regarding SAML setup with Active Directory ADFS for setting the “Relying Party Trust Identifier” were corrected. Although the settings will continue to work, it is encouraged that you modify those settings. |
|
Disabled the xmlsec1-based SAML library in favor of the re-enabled and improved SAML library. |
||
v5.24.0 |
A new configuration setting, |
|
The As an example, if you are using
|
||
Due to fixing performance issues related to emoji reactions, the performance of the upgrade has been affected in that the schema upgrade now takes more time in environments with lots of reactions in their database. These environments are recommended to perform the schema migration during low usage times and potentially in advance of the upgrade. Since this migration happens before the Mattermost server is fully launched, non-High Availability installs will be unreachable during this time. The migration is a single line of SQL and can be applied directly to the database through the MySQL/PSQL command line clients if you prefer to decouple this from restarting the Mattermost server. It is fully backwards compatible so the schema change can be applied to any previous version of Mattermost without issue. During the time the schema change is running (~30s per million rows in the Reactions table), if end users attempt to react to posts, the emoji reactions will not load for end users. MySQL: PostgreSQL: |
||
On mobile apps, users will not be able to see LDAP group mentions (E20 feature) in the autocomplete dropdown. Users will still receive notifications if they are part of an LDAP group. However, the group mention keyword will not be highlighted. |
||
SAML Setting “Use Improved SAML Library (Beta)” was forcefully disabled. Follow instructions at
https://docs.mattermost.com/onboard/sso-saml.html for enabling SAML using the feature-equivalent |
||
v5.22.0 |
Due to fixing performance issues related to emoji reactions, the performance of the upgrade has been affected in that the schema upgrade now takes more time in environments with lots of reactions in their database. These environments are recommended to perform the schema migration during low usage times and potentially in advance of the upgrade. Since this migration happens before the Mattermost server is fully launched, non-High Availability installs will be unreachable during this time. The migration is a single line of SQL and can be applied directly to the database through the MySQL/PSQL command line clients if you prefer to decouple this from restarting the Mattermost server. It is fully backwards compatible so the schema change can be applied to any previous version of Mattermost without issue. During the time the schema change is running (~30s per million rows in the Reactions table), if end users attempt to react to posts, the emoji reactions will not load for end users. MySQL: Postgres: |
|
The Channel Moderation Settings feature is supported on mobile app versions v1.30 and later. In earlier versions of the mobile app, users who attempt to post or react to posts without proper permissions will see an error. |
||
Direct access to the |
||
SAML Setting “Use Improved SAML Library (Beta)” was forcefully disabled. Follow instructions at
https://docs.mattermost.com/onboard/sso-saml.html for enabling SAML using the feature-equivalent |
||
v5.21.0 |
Honour key value expiry in KVCompareAndSet, KVCompareAndDelete, and KVList. We also improved handling of plugin key value race conditions and deleted keys in Postgres. |
|
SAML Setting “Use Improved SAML Library (Beta)” was forcefully disabled. Follow instructions at
https://docs.mattermost.com/onboard/sso-saml.html for enabling SAML using the feature-equivalent |
||
v5.20.0 |
Any pre-packaged plugin
that is not enabled in the |
|
Boolean elements from interactive dialogs are no longer serialized as strings. While we try to avoid breaking changes, this change was necessary to allow both the web and mobile apps to work with the boolean elements introduced with v5.16. |
||
v5.19.0 |
|
|
v5.18.0 |
Marking a post unread from the mobile app requires v1.26 or later. If using v5.18, but mobile is on v1.25 or earlier, marking a post unread from webapp/desktop will only be reflected on mobile the next time the app launches or is brought to the foreground. |
|
The Go module path of |
||
Removed |
||
Removed the ability to change the type of a channel using the |
||
v5.16.0 |
Support for Internet Explorer (IE11) is removed. See this forum post to learn more. |
|
The Mattermost Desktop v4.3.0 release includes a change to how desktop notifications are sent
sent from non-secure URLs |
||
When enabling Guest Accounts, all users who have the ability to invite users will be able to invite guests by default. System admins will need to remove this permission on each role via System Console > Permissions Schemes. In Mattermost Server version 5.17, the system admin will be the only role to automatically get the invite guest permission, however the fix will not be applicable in 5.16 due to database migration processes. |
||
v5.14.0 |
Webhooks are now only displayed if the user is the creator of the webhook or a system administrator. |
|
With the update from Google+ to Google People, system admins need to ensure the |
||
v5.12.0 |
If your plugin uses the |
|
Image link and YouTube previews do not display unless System Console > Enable Link Previews is enabled. Please ensure that your Mattermost server is connected to the internet and has network access to the websites from which previews are expected to appear. Learn more here. |
||
|
||
Added the ability to enforce the administration of teams/channels with Group Sync. If Group Sync is enabled, all team and channel admin designations will be lost upon upgrade. It is highly recommended that prior to upgrading, Team and channel admins are added to admin-specific LDAP groups corresponding to their teams and channels. After upgrading, those groups will need to be role-synced to the Team or channel admin role. |
||
v5.11.0 |
If your integration uses This change was made because |
|
v5.10.0 |
|
|
v5.9.0 |
If If the setting is not defined in the We recommend setting |
|
The public IP of the Mattermost application server is considered a reserved IP for additional security hardening in the context of untrusted external requests such as Open Graph metadata, webhooks, or slash commands. See documentation for additional information. |
||
v5.8.0 |
The local image proxy has been added, and images displayed within the client are now affected by the |
|
v5.6.0 |
Built-in WebRTC is removed. See here for more details. |
|
If
DELETE FROM PublicChannels;
INSERT INTO PublicChannels
(Id, DeleteAt, TeamId, DisplayName, Name, Header, Purpose)
SELECT
c.Id, c.DeleteAt, c.TeamId, c.DisplayName, c.Name, c.Header, c.Purpose
FROM
Channels c
WHERE
c.Type = 'O';
The queries above rebuild the materialized Note This migration is not required if the experimental |
||
v5.4.0 |
Mattermost mobile app version 1.13+ is required. File uploads will fail on earlier mobile app versions. |
|
In certain upgrade scenarios the new Allow Team Administrators to edit others posts setting under General then Users and Teams may be set to True while the Mattermost default in 5.1 and earlier and with new 5.4+ installations is False. |
||
v5.3.0 |
Those servers with Elasticsearch enabled will notice that hashtag search is case-sensitive. |
|
v5.2.0 |
Those servers upgrading from v4.1 - v4.4 directly to v5.2 or later and have Jira enabled will need to re-enable the Jira plugin after an upgrade. |
|
v5.1.0 |
|
|
v5.0.0 |
All API v3 endpoints are removed. See documentation to learn how to migrate your integrations to API v4. |
|
|
||
A Mattermost user setting to configure desktop notification duration in Account Settings > Notifications > Desktop Notifications is removed. |
||
Slash commands configured to receive a GET request will have the payload being encoded in the query string instead of receiving it in the body of the request, consistent with standard HTTP requests. Although unlikely, this could break custom slash commands that use GET requests incorrectly. |
||
A new |
||
A new |
||
An unused |
||
This release includes support for post messages longer than the default of 4000 characters, but may require a manual database migration. This migration is entirely optional, and need only be done if you want to enable post messages up to 16383 characters. For many installations, no migration will be required, or the old limit remains sufficient. To check your current post limit after upgrading to 5.0.0, look for a log message on startup:
As of 5.0.0, the maximum post message size is 16383 (multi-byte) characters. If your logs show a number less than this limit and you want to enable longer
post messages, you will need to manually migrate your database as described below. This migration can be slow for larger To migrate a MySQL database, connect to your database and run the following:
To migrate a PostgreSQL database, connect to your database and run the following:
Restart your Mattermost instances. |
||
Deployments on Enterprise E20 will need to enable |
||
v4.10.0 |
Old email invitation links will no longer work due to a bug fix where teams could be re-joined via the link. Team invite links copied from the Team Invite Link dialog, password reset links and email verification links are not affected and are still valid. |
|
Server logs written to System Console > Logs and to the |
||
Team icons with transparency will be filled with a white background in the Team sidebar. |
||
Those servers with SAML authentication enabled should upgrade during non-peak hours. SAML email addresses are migrated to lowercase to prevent login issues, which could result in longer than usual upgrade time. |
||
If you use PostgreSQL database and the password contains special characters (e.g. |
||
v4.9.0 |
To improve the production use of Mattermost with Docker, the Docker image is now running a as non-root user and listening on port 8000. Please read the upgrade instructions for important changes to existing installations. |
|
Several configuration settings have been migrated to roles in the database and changing their
|
||
The behavior of the |
||
If using Let’s Encrypt without a proxy server, the server will fail to start with an error message unless the Forward80To443 If forwarding port 80 to 443, the server will fail to start with an error message unless the ListenAddress |
||
v4.6.2 |
If using Let’s Encrypt without a proxy server, forward port 80 through a firewall, with the Forward80To443 |
|
v4.4.0 |
Composite database indexes were added to the |
|
LDAP sync now depends on email. Make sure all users on your AD/LDAP server have an email address or that their account is deactivated in Mattermost. |
||
v4.2.0 |
Mattermost now handles multiple content types for integrations, including plaintext content type. If your integration suddenly prints the JSON payload data
instead of rendering the generated message, make sure your integration is returning the |
|
By default, user-supplied URLs such as those used for Open Graph metadata, webhooks, or slash commands will no longer be allowed to connect to reserved IP addresses including loopback or link-local addresses used for internal networks. This change may cause private integrations to break in testing environments, which may point to a URL such as http://127.0.0.1:1021/my-command. If you point private integrations to such URLs, you may whitelist such domains, IP addresses, or CIDR notations via the AllowedUntrustedInternalConnections config setting in your local environment. Although not recommended, you may also whitelist the addresses in your production environments. See documentation to learn more. Push notification, OAuth 2.0 and WebRTC server URLs are trusted and not affected by this setting. |
||
Uploaded file attachments are now grouped by day and stored in |
||
Mattermost /platform` repo has been separated to |
||
v4.0.0 |
(High Availability only) You must manually add new items to the |
|
v3.9.0 |
Old email invitation links, password reset links, and email verification links will no longer work due to a security change. Team invite links copied from the Team Invite Link dialog are not affected and are still valid. |
|
v3.8.0 |
A change is required in the proxy configuration. If you’re using NGINX:
If you are using a proxy other than NGINX, make the equivalent change to that proxy’s configuration. |
|
You need to verify settings in the System Console due to a security-related change.
|
||
Backwards compatibility with the old CLI tool was removed. If you have any scripts that rely on the old CLI, they must be revised to use the new CLI. |
||
v3.6.0 |
Update the maximum number of files that can be open.
|
|
(Enterprise Only) Previous |
||
v3.4.0 |
If public links are enabled, existing public links will no longer be valid. This is because in earlier versions, existing public links were not invalidated when the Public Link Salt was regenerated. You must update any place where you have published these links. |