Extended Support Release Discussion

Summary
——————

Mattermost currently releases a new version on the 16th of every month, with security fixes backported for three releases. However, we’ve heard from some community members that they prefer to upgrade less frequently.

As a result, we’re considering releasing an Extended Support Release (ESR) version of Mattermost. No decision has been made yet, but if an ESR is created it would be supported with security backports for up to a year. Other bug fixes may also be considered if they have a high enough severity or effect enough people.

Mobile Applications
—————————
Before the ESR version is released, we also need to make a decision for how mobile app support will be handled.

Our proposed plan is to release an ESR version of the Mattermost mobile app in GitHub, but not on the app stores. Deployments using the ESR version can then choose to either distribute the ESR mobile apps themselves, or use the Mattermost Classic mobile applications.

The other option considered was releasing an LTS mobile app in Google Play and the Apple App Store. However, there was concern that we already have two mobile applications (Mattermost and Mattermost Classic), and adding a third may increase confusion about which app should be used. In addition, if we end up having multiple ESR versions it could increase confusion even further.

Feedback
—————

We would love to hear any feedback you have, including thoughts on the following questions:

  1. What do you think of our proposed plan?
  2. How often do you upgrade Mattermost currently, and how often would you ideally like to upgrade to a release containing new features?
  3. Do you use the Mattermost or Mattermost Classic mobile apps? If so, was it downloaded from the app store or distributed a different way?

Greetings,
Yes! I use MM both at work (paid Gitlab subscription) and at my house (Gitlab community for friends and family).

1 What do you think of our proposed plan?
I like it! I mean, I’m going to patch/update whenever Gitlab does. But I also tend to prefer LTS releases. I don’t like things moving around all the time or being in constant state of disruption (not that MM did this, just my preference for LTS).

2 How often do you upgrade Mattermost currently, and how often would you ideally like to upgrade to a release containing new features?
Whenever Gitlab releases a new update. If the integration between the two is good and I don’t have to fiddle with it at all, then that is my happy zone. :smiley:

3 Do you use the Mattermost or Mattermost Classic mobile apps? If so, was it downloaded from the app store or distributed a different way?


I would PREFER to have it in the f-droid repo, but the above works (my tablet is one of those fairly new tablets that works great, but will never ever get an update from anyone ever because it is Android and they only care about making the device not patching it or updating it…Gotta “love” the broken Android ecosystem…anyway, point is Google Play doesn’t work right but f-droid is amazing and I do appreciate that I can pull the apk right from your git repo - Thanks!)

1/ What do you think of our proposed plan?
As long as :

  • a mobile client “ESR compatible” is avalaible is the stores (I don’t know if it’s possible to ensure compatibility with “cutting-edge” and ESR in the same version but I agree with you : the situation is already confused with the Classic version which many users don’t understand the purpose)
  • there’s only one ESR at a time
    I think an ESR version is a good idea !

2/ How often do you upgrade Mattermost currently, and how often would you ideally like to upgrade to a release containing new features?

Only when a security fix forces us to upgrade or when a new feature is really needed.
New features every 6 months is a good choice IMHO (for an ESR). Mattermost is still a young product and is evolving quickly.

3/ Do you use the Mattermost or Mattermost Classic mobile apps? If so, was it downloaded from the app store or distributed a different way?
We encourage our users (~500) to download Mattermost mobile app from the stores (Android and iOS).

Regards,

Hi all,

I’m not against longer releases. It is better for the team to include more features and longer time for testing making sure new releases are stable.

But … mattermost is still new and has got some very important features amiss that needs to be addressed as soon as possible.

  • Message engine needs ironing up. Messages are the main feature of this product and there are still some issues that need to be addressed.
  • File download and upload support. Files, independent of the type, must have basic support throught out the product.
  • End to end encryption. One big reason why users use selfhosted products is because they are looking for their privacy.

All those three topics are a reason for someone to not choose Mattermost as their message service therefore I believe the dev should be focusing on getting those implemented and released as quick as possible.

Conclude: Longer release dates is great but only after the basic features are sorted.

I upgrade only when there are interesting new features in the release.

I use and request my users to install only Mattermost since Mattermost Classic requires more server processing and bandwidth.

1 Like

We currently upgrade bimonthly, but we are considering going to a monthly schedule. Through scripting I have reduced downtime during an upgrade to about 1 second, with the connection being stateless, most users don’t realize it has happened. I like the frequent upgrades adding new features and fixes.

Thanks everyone for the feedback so far, we’re taking this all into consideration.

@RbDev - it would be great to discuss some of the features you mentioned more in depth. Would you be able to open a new forum post so we can discuss more in depth? Or alternatively if you’d like to sign up for our team Mattermost site we can chat there (I’m @lindsay).

Hi Lyndsay,

Nice to see you back. We are going to get some action now.

The topics I’ve mentioned already exist:
1)messages

2)file support

3)security

Thanks RbDev, I’ve responded in the linked threads.