Any Mautic version that doesn't end with '.9' is NOT fit for use in business!

Let me start by saying that in general Mautic developers are doing a fairly good job.



Sadly, that doesn’t change the fact that:

Any Mautic version where the version number doesn’t end with “.9” is NOT fit for use in a production environment in business!



I postulate that as a fact and until anyone can prove otherwise it will remain a fact.

A sad fact.



And of course, we all hope for this to change in the future, but I think there’s little hope for that to ever happen WITHOUT introducing a major change to the way the development of this software is managed.

Here’s why:



As far as I can tell (and again, feel free to prove me wrong if you can back up with facts), as far as I can tell there has never been a Mautic version (since Mautic 1.4) that is actually fit for use in a production environment in business.



And because in the current version (v.2.7.1) no new features were introduced at all and it was all dedicated to squashing the bugs, I was really hoping that this new version will finally be one that is fit for use in a production environment in business.

Nope. I was disappointed. Again!



Please understand:

Just because you really polish one side of your car and the wheels are turning on that side, it doesn’t automatically mean that this car is fit for use.

If both wheels or at least one of the wheels on the other side came off, you cannot use that car!

A car with 2 wheels fallen off is certainly not fit for use in business. Even if you polish the entire car to perfection.



And if someone tells you that this new version of Mautic has removed 30 bugs (!) without introducing a single new feature,

my question would be:

What about the other 99 bugs that are open right now, right this second?

https://github.com/mautic/mautic/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20label%3Abug



Sure it is great that you squashed 30 bugs. Good job!

But how many of those 99 open bugs are an equivalent to a wheel fallen off?

I know, I reported one today. There’s at least one wheel fallen of the “Mautic car 2.7.1” right now

and I postulate that there has never been (since version 1.4) a single version of Mautic with “all wheels turning”.



And again:

I’m NOT trying to diminish the work Mautic developers have done until now.



What I AM saying is that there is a structural, fundamental problem with the way the development of this software is being managed and until that’s fixed there is no hope of ever getting a Mautic version with all “wheels turning”.



[h]So, here’s my proposal to solve this problem:[/h]



After introducing a release with new features i.e. a version that ends with “.0” (such as 2.7.0 etc.),

release 9 versions where you DON’T introduce a single new feature and solely focus on fixing the bugs!




In other words, I suggest that 9 out of every 10 versions should focus entirely on elimination of bugs WITHOUT introducing a single new feature!



Because if you do that, then a version that ends with “.9” such as 2.7.9 for example

will certainly become fit for use in a production environment in business.



That would allow folks who actually want to use Mautic in a production environment in business to stick to Mautic versions that end with “.9” and be pretty sure that all “wheels” on those versions are turning!



P.S.

And just in case you claim that “lots of people have Mautic installed in a production environment in business”,

my questions would be:

  • Having it “installed” is surely not the same thing as actually actively using it in a production environment, is it?

    Also:
  • How many people who have installed Mautic in their production environment are using it without being aware that some of the “wheels aren’t turing”? (there are people driving a car with the handbreak on and wondering why it’s slow)
  • What if the majority of people using Mautic are “driving a Mautic car where at least one wheel is stuck or not properly turning” without even realizing it?
  • Can you prove that’s not the case if you claim “lot of people are using it”?



    Mautic is a complex software and it’s easy to miss that one or two “wheels” aren’t turning.

    But just because you miss that fact, it doesn’t automatically make that software version fit for use in a production environment in business, does it?



    I’m not suggesting that “all bugs” can be eliminated.

    I’m just saying that if you dedicate 9 versions solely to fixing the bugs without introducing a single new feature, then the 9th version will be pretty darn fit for use in a production environment in business.

    At least all “wheels” on that 9th version will be turning!

Let me start by saying that in general Mautic developers are doing a fairly good job.

Sadly, that doesn’t change the fact that:
Any Mautic version where the version number doesn’t end with “.9” is NOT fit for use in a production environment in business!

I postulate that as a fact and until anyone can prove otherwise it will remain a fact.
A sad fact.

And of course, we all hope for this to change in the future, but I think there’s little hope for that to ever happen WITHOUT introducing a major change to the way the development of this software is managed.
Here’s why:

As far as I can tell (and again, feel free to prove me wrong if you can back up with facts), as far as I can tell there has never been a Mautic version (since Mautic 1.4) that is actually fit for use in a production environment in business.

And because in the current version (v.2.7.1) no new features were introduced at all and it was all dedicated to squashing the bugs, I was really hoping that this new version will finally be one that is fit for use in a production environment in business.
Nope. I was disappointed. Again!

Please understand:
Just because you really polish one side of your car and the wheels are turning on that side, it doesn’t automatically mean that this car is fit for use.
If both wheels or at least one of the wheels on the other side came off, you cannot use that car!
A car with 2 wheels fallen off is certainly not fit for use in business. Even if you polish the entire car to perfection.

And if someone tells you that this new version of Mautic has removed 30 bugs (!) without introducing a single new feature,
my question would be:
What about the other 99 bugs that are open right now, right this second?
https://github.com/mautic/mautic/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20label%3Abug

Sure it is great that you squashed 30 bugs. Good job!
But how many of those 99 open bugs are an equivalent to a wheel fallen off?
I know, I reported one today. There’s at least one wheel fallen of the “Mautic car 2.7.1” right now
and I postulate that there has never been (since version 1.4) a single version of Mautic with “all wheels turning”.

And again:
I’m NOT trying to diminish the work Mautic developers have done until now.

What I AM saying is that there is a structural, fundamental problem with the way the development of this software is being managed and until that’s fixed there is no hope of ever getting a Mautic version with all “wheels turning”.

[h]So, here’s my proposal to solve this problem:[/h]

After introducing a release with new features i.e. a version that ends with “.0” (such as 2.7.0 etc.),
release 9 versions where you DON’T introduce a single new feature and solely focus on fixing the bugs!

In other words, I suggest that 9 out of every 10 versions should focus entirely on elimination of bugs WITHOUT introducing a single new feature!

Because if you do that, then a version that ends with “.9” such as 2.7.9 for example
will certainly become fit for use in a production environment in business.

That would allow folks who actually want to use Mautic in a production environment in business to stick to Mautic versions that end with “.9” and be pretty sure that all “wheels” on those versions are turning!

P.S.
And just in case you claim that “lots of people have Mautic installed in a production environment in business”,
my questions would be:

  • Having it “installed” is surely not the same thing as actually actively using it in a production environment, is it?
    Also:
  • How many people who have installed Mautic in their production environment are using it without being aware that some of the “wheels aren’t turing”? (there are people driving a car with the handbreak on and wondering why it’s slow)
  • What if the majority of people using Mautic are “driving a Mautic car where at least one wheel is stuck or not properly turning” without even realizing it?
  • Can you prove that’s not the case if you claim “lot of people are using it”?

Mautic is a complex software and it’s easy to miss that one or two “wheels” aren’t turning.
But just because you miss that fact, it doesn’t automatically make that software version fit for use in a production environment in business, does it?

I’m not suggesting that “all bugs” can be eliminated.
I’m just saying that if you dedicate 9 versions solely to fixing the bugs without introducing a single new feature, then the 9th version will be pretty darn fit for use in a production environment in business.
At least all “wheels” on that 9th version will be turning!

Hi @abb but all my Mautics are working 100% in real business environment. You have errors or something?

@abb why are you continuing with the bashing? Shouldn’t someone be the bigger person? So, vcdesigns doesnt agree with you and didn’t choose the nicest way of saying it, that’s ok. You are entitled to your opinion. However continuing a flame war is not going to encourage people to take your original idea seriously.

All i just read was a bunch of complaining, mautic is open source it’s free to people who want to use it, develop and be part of ideas and solutions to make mautic become better and bigger. All i see is someone who has a stick up their butt because they can’t get something to be working 100 percent all the time. Guess what you pay for what you get. Just like any application you want something that works 100 percent right out of the gate, no such thing. Microsoft, Google, any software development company have all working versions of something and yet all of them still have bugs, and arn’t working 100 percent. The one thing that does make sense is how versions are put out. bug fixes and should be all the minor versions such as 2.7.0 and 2.7.1 and then for more fixing it should be 2.7.2 and so on. when new addons or improvments to promise new features than it should be a new version all together such as 3.0 this .9 is stupid repeating .9 over and over anything with .# is always patches and fixes. Look at microsoft office 2016 office has had seious .# version for fixes nothing is ever new features, that is when it’s an entire new version. Mautic to work extremly well in a business environment you need to be on a dedicated server platform, if your using shared or even vps your limited to having problems no matter what. Having full control of your own server is the key to success with any online application. I have had issues with mautic, i use a dedicated hosting server and i’m running as of 2.7.1 update no errors show up anymore in my log file as before it was just 1 error over and over and that has been fixed with this past error. Bitching doens’t fix things giving feedback and showing by video or providing the debugging and log errors to others to look at is what helps fix things. I don’t see that talked about anywhere on your so called issues, besides a bitch fest.

@vcdesigns Judging by your post you appear to be drunk right now.
I suggest you sober up and then come back and re-read my post.
Also, occasionally hitting the enter key to insert a paragraph is a good idea.
(but I trust you know that when you’re sober)

sorry i don’t drink, to busy working. i also don’t care if my grammer is bad or my pharagraphs are not to your standards. You bitch about mautic is all i read no actual imput on what your actual problems with it are for errors to report other than putting down developers, you justify how mautic suchs and than say how good something is than get on the developers on how to do their job more or less. I have had problems with mautic as well, those issues been fixed because i don’t bitch and piss off the main developers. I really don’t care what you think of me, i’m standing up and backing up Mautic and their developers.

Ok, ok enough, both of you.

@abb I agree with your points and in another thread suggested a feature freeze between versions. I also agree with vcdesigns in that when you have a problem simply saying there are problems is not going to get them resolved. I know you have submitted bug reports on GitHub , and that is helpful, perhaps on this thread give examples of ones that are causing you the most trouble.

@vcdesigns Everyone is entitled to their opinion, and only by everyone speaking freely will this commumuty be able to build the best end result possible. We may or may not agree with what others say, or how they express themselves, but we cannot go about bashing each others opinions.

@vcdesigns I’m glad that you don’t care what I think of you because I think that a guy with an IQ of a drunk person won’t be able to run any business. The IQ of a drunk person, on the other hand, gets lowered only temporarily. So, I was really hoping that your IQ issue was temporary. Really sad to hear that it’s permanent.
I wish you well despite your misfortune.
And also: Good luck with your imaginary business! It’s tough out there!

It seems to me that @abb’s primary point was that changes should be made to the development process.

The process should be up for discussion in any development environment (commercial or open source) and criticism of the process should not be taken personally.

I love Mautic. We run 20 or so instances for our clients and are increasing our commitment daily. I think @abb’s suggestion is a good one and that something along these lines should be implemented.

The reason it’s a good idea is not that it will result in all bugs being squashed but that it will give all users the ability to make a somewhat objective assessment of their confidence installing Mautic in various environments.

Obviously you can’t manifest a huge application like this out of thin air without also generating bugs. But, we need a way to communicate the status of releases. In other words the ratio of cool new features to possible bugs. With a rule like the one @abb suggests, we would have this. At worst, it’s valuable signalling. At best, it’s a faster development process in the long run.

As mentioned earlier in the thread I also agree with feature freezes between versions. This would allow people to choose the point along the updates cycle they are comfortable upgrading to.

@manageit
Because it’s fun to squeeze out the last 2 brain cells of a troll who had chosen to attack me and continues to spill his brainless off-topic garbage. If there was a moderator in this forum, he would have removed the brainless troll or at least reprimanded that idiot for personal attacks in a thread intended to discuss a serious topic. But since there’s no such moderator, I will kick the troll where it hurts him most. Do you have any problems with that?

I have ZERO problems with people disagreeing with me. It’s perfectly normal that different people disagree with different opinions. That’s why there’s a DISCUSSION FORUM. So, I welcome ANY civil discussion on the topic I started here. ANY opinion is welcome in a civil discussion regardless of whether a person agrees or disagrees with me or has a completely different opinion.

However, if a brainless, moronic IDIOT-TROLL chooses to make personal attacks on me, he is NOT expressing ANY opinions.
He is just acting like a brainless, moronic IDIOT-TROLL. So, I treated him like that.
But hey, if you would have actually read his post, you would have realized that too. Well, at least now you do. :slight_smile:

@ninjoan
This topic has absolutely nothing to do with any specific bugs of any kind.
I specifically posted this thread in a GENERAL discussion forum because it’s a general discussion topic
regarding a general systemic issue with the management of the software development.

I said that until this structural, systemic issue with the management doesn’t get fixed,
Mautic won’t be fit for use in a production environment in business. Regardless of what version it is.

Furthermore, I have suggested a very simple and clear way to fix the systemic management issue.

Take WordPress as an example.
If I have a business website running on WordPress version 4.6.2 or something and WordPress then releases version 4.6.3, then I can be pretty sure that this new version won’t break my business website and it’s pretty safe to upgrade.
When on the other hand, WordPress releases version 4.7.0 or 4.7.1 etc., then I know that unless I have extensively tested version 4.7.X in a test environment and after this extensive testing can confirm that it won’t break anything, then and ONLY THEN can I safely upgrade to that new WordPress version in a production environment in business.

[h]Doing it otherwise would be suicidal and STUPID![/h]
(especially, if you have 60+ add-ons installed including BuddyPress and bbPress and have a large number of users that are very important to your business)

And, of course, in case the new major WordPress version does break things in my testing environment, I have to first fix all those things before I can upgrade in my production environment.

But my point is:
There’s no guesswork and no risk for me with WordPress.
With WordPress I know:
Unless it’s a major version, I can safely upgrade and expect that everything still keeps working as it was before.
And I also know with WordPress: If it’s a major version change, I absolutely CANNOT upgrade BEFORE having extensively tested the new major version in a testing environment.

Mautic rushes from one major version to the next.
And because of the systemic, structural issue with the management,
there has never been a single version of Mautic that is actually fit for use in a production environment in business.

Moreover, I predict:
[h]There will NEVER be a Mautic version that is actually fit for use in a production environment in business UNLESS and UNTIL the systemic issue with the management gets fixed.[/h]

Feel free to prove me wrong.

+1 total agreed

The mayor issue with mautic is every update… fail.
EVERY SINGLE ONE.

Sorry is true.

They need to make a better update solution. Is insane how much people quit mautic about this issue (update=broke). You cannot run mautic for a bussiness, only for testing/fun.

P.S.
There are now 136 open bugs (was 99 when I started this thread and there was NO new version release since I started this thread):
https://github.com/mautic/mautic/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20label%3Abug
Many of those open bugs have the label “ready to test”,
BUT if the next Mautic version is gonna be 2.8.0, then it really doesn’t matter.
Because that would be just another major version riddled with lots of new bugs
and thus NOT fit for use in a production environment in business.

+1 for process.

About 3 weeks ago, a client’s junior level sys admin updated a Mautic installation (without backing up or asking my approval) and he completely hosed the installation. I spent 10+ hours (unbillable) supporting him with getting that instance back online. At the moment, the client has completely lost faith in Mautic and I am finding myself explain to them why to stick it out instead of moving back to MailChimp. I’m personally in a situation where I’m trying not to throw the junior sys admin under the bus - and I’m trying to not throw Mautic under the bus – and I’m trying to protect my own relationship/faith with the client. The lack of process/documentation/testing has cost me.

If an update is exposed in the UI, should a user expect to apply it without disaster? If we are talking about WordPress, the answer is most likely ‘yes’. This isn’t about blasting Mautic or the development team. I think everyone here is very excited about Mautic and sees the genius of the solution. We’re simply looking for stability to be a higher priority.

With my instance of Mautic – I’m holding at 2.5.1 but campaign triggers cause SQL errors (meaning I can’t add new contacts to a campaign and expect them to get email) and I’m not able to upgrade seamlessly to 2.7.1 without creating a bunch of errors (all of these issues have been explained by others in the forum).

In my experience, forum support responses take a typical red tape unfriendly geek approach and assumes that the issue reporter is an idiot. Honestly, I usually don’t post in forums and search a bunch of threads to find a solution (as we know, there’s no one combining threads). I’m honestly using the community to beta-test, go through the pain for me, and find a resolution before I make any changes.

I would LOVE to help with establishing a better process around development, documentation, and issue resolution. Addressing these three challenges will help Mautic move forward strongly towards being a more robust and mature product (and will help better utilize the more techical savvy community members). I like to focus on solutions so – here’s what I would propose to help us

  1. Beta-Testing on an instance available to a short list of community members: I would propose a Bitnami AWS instance

  2. Beta-Test Sign-off before release. Before a release, we should not only have developers signing off on updates - we should have our short list of Community Super Users signing off. I understand that some of this happens via the git repo; however, I’m not sure if there’s a clear understanding of how updates are utilized by marketing professionals (the business that we serve) before a release. This is our opportunity to get that sign-off.

  3. Upgrade testing: Clear upgrade process from 2.5.x to Current version or any supported version to the newest release.

  4. Upgrade documentation. We can’t assume that this is a hands-off upgrade. Apparently, there are times when we need to run specific scripts or SQL queries to successfully upgrade. This needs to be documented before a release is published.

And so on. If there’s any interest in creating order around these ideas, I would love to help. SO – bottomline. +1 for process. We need it.

Respectfully,

Ray

@gigcity Thank you for sharing your experience and suggestions!
This:

underlines my point that Mautic is NOT fit for use in a production environment in business.
And there has never been a single version of Mautic that is fit for that purpose.

Yes, it’s not the fault of the developers. The developers are doing good work.
It’s the fault of the management. Allowing to rush from one major version to the next will never produce a version that is actually usable in a production environment in business.

Regarding your suggestions:
Those suggestions are good but they would NOT fix the general issue that’s the problem here.
[h]To fix the issue, the management MUST freeze the addition of any and all new features (after a major version release) UNTIL 9 different versions have been released i.e. 9 versions that do not add a single new feature but are instead focusing on making the existing features actually work in a production environment in business.[/h]

Then we can be pretty darn sure that a version that ends with X.X.9 will be actually usable in a production environment in business.

Also, important to use those 9 minor versions for fleshing out and updating the DOCUMENTATION!
For a software with this level of complexity, the current documentation is a complete piece of SHIT!

@abb [quote]For a software with this level of complexity, the current documentation is a complete piece of SHIT![/quote]

While your motivational tactics are limp, I’d consider channelling all that range towards solving the problem. You are rather prolific during your short visits, in two weeks you created 2 posts, 7 replies, 6 pages of text, 1, 929 words, 9,241 characters (not including spaces), and 11,166 characters (with spaces).

Imagine if you dedicated that much time, twice a month or for 3 months in a row, towards authoring documentation for Mautic?

@redneckbob exactly…

@redneckbob
I’d gladly help regarding authoring documentation for Mautic.
[h]BUT that would be pointless because so far there has never been a single version of Mautic that is fit for use in a production environment in business and I predict that unless and until they fix the management issue I outlined here there never will be a version that’s actually usable in a production environment in business.[/h]

So, doing any improvements to the documentation BEFORE that management issue gets fixed, would be a complete waste of time. But you could have figured that on your own if you had given it at least 2 seconds of thought.

I’m happy to help with Mautic documentation.

If you’re talking about documentation here: https://mautic.org/docs/en/index.html, it’s not clear HOW to submit edits. If access is open to the community, Is there a team vetting those updates?

I think the challenge around getting community support is – process. We’re not clear on how we can help. (QA of proposed releases included).

btw, the OP is frustrated. That’s OK. It’s his experience - and it’s a valid experience. We may not like the specific words being used but the wish that he’s expressing can help us all. Let’s use my client as an example, I simply want a clean upgrade path to 2.7.1 and I want campaigns to work. I don’t have a clear understanding of how to reach that goal. The OP’s suggestions are completely aligned with my need for a more stable solution.

SO – what do we do to move forward? I’m happy to write LOTS of documentation about the things that I am familiar with. How can we get going now with that contribution and the contributions of others around Beta testing and QA? How can we establish feature freeze between major versions? Point me the way, and I’m happy to help.

Respectfully,

Ray