Mautic Release/Upgrade Strategy is Misguided?

Development
1

Hello,

May I ask the developers why they have chosen to release Mautic 6.x (Symfony 6) and then immediately start working on a Mautic 7.x (Symfony 7) release when Symfony 8 is due to be released shortly. Surely a single upgrade direct to Mautic 8 (Symfony 8) would have been a more sensible option ?

Each time there is a Symfony version hop custom code needs rewriting, plugins need rewriting and purchased plugin need re-buying etc. All adding to the overhead cost of running Mautic.

I’ve just started running Mautic 6.x in production and had problems with regards to doing minor upgrades. Others in the forum are reporting issues migrating from V5.x to V6.x. If you look at the forum not many solutions are being offered to users experiencing these problems and in my case there was a long delay before anyone responded.

Please remember that our businesses rely on Mautic functioning to generate revenue. Downtime and troubleshooting version upgrades is something we definitely want to avoid. Many of us are either IT experts or employ IT experts and don’t need professional services. We just need a little guidance from the developers to fix these problems ourselves and that should be done in the forums like in many other good open source projects. Or at the very least we think that we are being listened too.

I for one would like to see more effort put into finding and fixing bugs and adding functionality to make Mautic better. I and others have suggested many good ideas on the forum which are un-actioned. Instead the development time is being spent on doing little Symfony version hops when bigger hops I think are more appropriate ?

I am also a little confused as to why quite old forum posts are being republished on the forum for Mautic 3 and blog posts from back in 2015 and 2021 etc . Surely these will confuse users who are using more recent versions. I don’t understand why the Mautic team thinks this is helping the Mautic community ?

I think Mautic is a wonderful open source project with a great future. And when you are developing your strategy just think about how often an upgrade is really needed and that upgrades must work 100% as per other good open source projects and commercial software. I think there is a better way forward and I kindly ask you to review your development strategy and rollout plans to make Mautic better for everyone.

Thanks.

2

Hi Andrew, I think all of us who were involved in defining the new release cycle are 100% in sync with your reasoning!
The only thing you missed is that M6 was intentionally created as a “bridge release” that can easily be skipped but helps us catching up with the Symfony release cycle.
As a result, we create really long and production-friendly cycles. Plus optional extra 2 years through ELTS.

Bottom line, the strategy:that we run at our agency:

  • skip M6
  • don’t use .0 versions - use LTS versions only
1 Like
3

Hi @andrew_c3 and thanks for asking these questions in a respectful way, it’s much appreciated. Responding with my Project Lead hat on! :top_hat: :smiley:

We spent a lot of time figuring out what was going to be the best way for us to both catch up with Symfony releases and get to a place where we can provide a lengthy period of support for each major version of Mautic for the exact business-focused reasons you mention.

You can read all about this here:

The long term vision is that each major version has five full years of support (two of which are through the Extended Long Term Support program).

We cannot just upgrade to Symfony 8 for a couple of reasons:

  1. Symfony isn’t even working on Symfony 8 yet. See Symfony releases, notifications and release checker for the timings of their releases

  2. When we make a major release, we aim to support Symfony’s Long Term Support version which is typically the *.4 release - these are supported by Symfony actively (bug fixes + security, no new features) for 3 years, and then security only fixes for another one year. This enables us to ensure that we can have that longer term stability for Mautic, because Symfony hasn’t yet ended security support for the long term support version by the time we ship the next major version. The LTS release isn’t yet available for the 7 series.

  3. There are other dependencies which we cannot bump without bumping Symfony - for example the big one is PHP but there are also many other dependencies that this impacts. These are just as critical for our users to be running supported versions as the Symfony updates.

  4. Waiting for Symfony to ship their 8.4 release, many of our enterprise customers would fall into problems because we’d be running on unsupported versions of Symfony - assuming we’re at Symfony 6 by then which would already be end of life.

  5. Jumping versions of Symfony is no small task. Often it requires extensive rewrites of major parts of Mautic - jumping more than one version is a massive undertaking. Not only do we have to do the extensive work to figure out what changes are needed for each of the versions we’re updating between, but we also have to actually do that work (which is why we’re behind with the 7.0 pre-releases currently). Most of this is being done by volunteers or in a few isolated cases, by developers working for an organisation who give them a small amount of hours each week to contribute to Mautic. We do not have any paid developers working for Mautic right now.

In terms of your comments about the responses in the forum, coming back to the fact that there are no developers being paid to work on Mautic full time right now, the responses you receive are from volunteers in the community who are doing their best to support each other and help people find answers to their questions. They are doing the best they can with the time they have.

A way you can help us to ‘put more effort into finding and fixing bugs and adding functionality to Mautic’ is to join us in testing new bug fixes and features. Did you know every single bug fix and feature requires at least two people, like you, helping to test it, plus a developer to review the code, and a release lead to merge?

Anyone can help with testing and we have regular onboarding sessions. Join us in #t-product on Slack to get involved and find an onboarding mentor.

Don’t have time? Want to do more? If your business relies on Mautic then please give back by becoming a Member of Mautic. This funding helps us to employ people to actually work full time on Mautic. We’re just in the process of recruiting a Senior Developer for this purpose thanks to the organisations who are helping us to drive Mautic forward.

As regards the blog post updates, we’re working through fixing a bunch of broken links which were causing some issues with our SEO. Unfortunately those posts were from our old Drupal site and aren’t connected with forum threads on the forums, so it’s posting them in the forums when the updates are made. Sorry for the inconvenience.

Feel free to join my office hours this afternoon (see Announcements on Slack) if you’d like to chat through any of the above!

4

Hello,

Thanks for your recommendations and comments. This is a general response to both posts above.

Yes I agree that only using LTS versions of Mautic is a very good strategy in general especially if you only use Mautic and have no aspirations of extending its feature set by writing your own code.

Yes I was aware that Mautic 6 was a bridge release. However if its an official release the developers think it production ready and have a strategy to migrate an instance of it to the next major release. Or the developers could have left it as a beta release only, making a clear statement its not production ready. Any how the community is not aware of your thinking and users are migrating from 5.x to 6.x and are having difficulty. Checkout the recent posts on the forum. I’ve been having trouble migrating minor 6.x upgrades as well. Ive never tried an upgrade on 5.x

I have aspirations of extending the function of Mautic. Half my working life I have written code but have little Symfony experience. I spun up a Mautic 5.x instance and tried to write a couple of very simple plugins which worked. I then spun up a Mautic 6.x instance and ported those plugins over and they needed modifying to support Symfony 6. The mods were not trivial they are structural.

The developers are migrating Mautic 6.x to Mautic 7.x and upgrading to Symfony 7. Again I’m fairly sure my simple 5.x plugins will need modifying again. And when the developers move to Symfony 8 I’m sure I will have the same problem. And so on and so on.

So right here an now do I develop code for Mautic 5, Mautic 6 or wait for the imminent Mautic 7. I don’t have the resource to learn to change the code for each small Symfony hop. I’m only advocating that if the Symfony hop was bigger then Mautic would be stable for longer which means the coding investment becomes a viable proposition.

The Symfony 8 release date is currently November 25 and there will be beta copies available for development purposes. I’m only asking the developers to consider the possibility of bigger Symfony hops. Link below.

However after reading your comments on this subject I think I’m personally better off by coding outside of the Mautic Symfony platform for the time being until the Mautic code base becomes more stable and then I can invest in writing Mautic plugins at a later date. What matters more to me is functionality not what version of Symfony is under the hood. With the only exception of security fixes etc.

Thanks for taking the time to read through these posts and your comments. Its been an eye opener on the project strategy moving forward.

Thanks.