| Ruth Cheesley (she/her) |
Hi folks, I’m Ruth and based in the UK. I’ve been involved with Mautic since it was launched, used to run an agency which specialised in Joomla and later Mautic. My background is in all things web/digital. I’m now Mautic Community Manager :slightly_smiling_face: Today has been great - amazing sunrises at the moment in the UK and blue skies, after a week of bad storms! |
| dbhurley |
I'm DB, founder of Mautic and excited to see the community continue to grow! |
| RGBguy |
Hey I am Kevin. I joined the channel as a happy lurker. Am and enthusiast and administrator for many self-hosted instances of Mautic. I also have been creating YouTube videos to help people get into using Mautic. |
| Ruth Cheesley (she/her) |
Happy lurkers most welcome @RGBguy :slightly_smiling_face: |
| Yosu Cadilla |
This is Yosu, Mautic freelancer. |
| john |
Hi, John here. Mautic developer as long as I can remember. Based in Prague. |
| jordan8037310 |
Hi, Jordan here. I run a development agency in Los Angeles along with @pvasilion. We are a blend of growth hackers / process consultants. Been on and off Mautic, and more recently on again :wink: . |
| kuzmany |
Hi, Kuzmany here. Mautic independent developer and contributor |
| Ruth Cheesley (she/her) |
We didn’t hit the beta release on Monday (it was a US holiday) - it would be good to be able to share when the beta will land, especially if it means pushing back the proposed launch in the first week of February. @dbhurley @alanhartless @john any insights there? |
| Ruth Cheesley (she/her) |
I think @norman has been triaging issues and keeping the board up to date here: https://github.com/orgs/mautic/projects/6 but I’m not sure how we’re identifying what needs to be fixed in order to release the beta, or what the blocks might be? |
| dbhurley |
I believe the beta is this week still...but I do think we'll need to push back the Feb date by a week |
| Ruth Cheesley (she/her) |
OK that’s helpful to know. Will it depend on how the beta goes, or are we pretty sure at this stage that we can hit a date that’s pushed back a week? |
| Ruth Cheesley (she/her) |
I mean, I would prefer we pushed back further and definitely, confidently hit the date, than push back a week and miss it |
| Yosu Cadilla |
Any pointers about what's the future of 2.X series (if any)? |
| Ruth Cheesley (she/her) |
@Yosu Cadilla if you take a look at 1.2 (https://mautic.slack.com/archives/CQMKV0RU1/p1579633641007900) that’s the place for the 2.x discussions I feel. |
| Yosu Cadilla |
I see there;s a 2.15.4 possibility discussed in #mautic-3 |
| Yosu Cadilla |
What's the view of the leadership on that? |
| Yosu Cadilla |
I'm not discussing, I'm asking |
| Ruth Cheesley (she/her) |
Please see the next topic |
| Yosu Cadilla |
OK |
| john |
I would like some input on the Mautic 3 scope. I can think of 2 BC breaking changes that need to happen and that are not part of M3 yet. They were already suggested during the M2 lifetime but refused or reverted as BC breaks:1. https://github.com/mautic/mautic/pull/6554 - to support emoticons and non-english languages like Japan.2. https://github.com/mautic/mautic/pull/7081 (merged but reverted) to support big databasesBoth of these will make the migration from M2 to M3 very difficult. But I repeat, it must be done anyway. One point why we should wait for M4 is that MySql 8 might migration for utf8mb4 simpler. It will be a pain to migrate to bigints on any MySql version. |
| Ruth Cheesley (she/her) |
The utf8mb4 thing is also what’s breaking the social listening iirc |
| Ruth Cheesley (she/her) |
can you quantify what you mean by ‘make the migration from M2 to M3 very difficult’ - difficult for who, the user? admin? Us writing the migration process? How difficult and why?If it has to be done at some point, is causing problems/bugs which are currently reported and will be painful whenever it is done, then I’d suggest we should get it done sooner than later.As a bare minimum we should make it super clear to folk to CHOOSE to use utf8mb4 when installing? |
| john |
It will take ages for bigger databases to migrate for both cases. Since MySql 8 the utf8mb4 migration will be fast. For the bigint migration, it will take a lot of time and we will have to drop the foreign keys before that, create them afterwards. That means some inconsistencies may happen and will require manual fixes. A nightmare for whoever updates Mautic. |
| Ruth Cheesley (she/her) |
For the time thing, we can give very clear directions on that, I guess. Only do at command line, don’t expect it to be done fast. etc.The inconsistencies part would be the bit that worries me. |
| john |
At this point it should be fairly easy to upgrade from M2 to M3. The usual way. If we implement the mentioned database changes then it might be easier to let users install M3 instance next to M2 and create some migrations script, maybe stored procedures to migrate row after row to the M3 database. Once that's done and they tested everything is working properly, they could switch to the M3 instance and delete the M2 instance. It can take days for bigger databases to migrate, but it shouldn't matter that much as there won't be any downtime. If we decide to include the 2 database changes, it may move the release date further. |
| Ruth Cheesley (she/her) |
I think as a user I would feel safer with setting up a new 3.x instance and running migration scripts, providing it was definitely the case that I could do a clean switch over.Maybe a daft question, but if it takes days to migrate then wouldn’t there be some discrepancies while the migration was happening (e.g. any data coming into the 2.x instance since the migration started)? |
| Ruth Cheesley (she/her) |
Maybe that’s something to consider if we went that route.What would be the consequences of delaying implementing those two PR’s until M4, for example? |
| john |
Except the one upside I mentioned (MySql8) it has only downsides. The instances will get bigger, it will be more of them. |
| john |
Stored procedures should push all new rows to the new table as soon as they are created. I think. We'd have to test it. |
| Yosu Cadilla |
And they are super fast! |
| Yosu Cadilla |
You can trigger these at any point you want I think |
| Ruth Cheesley (she/her) |
Right, so to my mind, it makes sense to have them in M3 if we can, and we have to see what we can do about the timeline side of things. Plus, ensuring that it’s super clearly documented.As users, I feel it would be a much better experience to have a new M3 instance and bring the data over, test it, then switch. Of course we need to make it very clearly documented as to why this is necessary (e.g. the time it takes, the complexity of the actions/safety of data, and how it addresses the points you raised above, the bugs it fixes and preventing the problem we already have getting worse etc) (edited) |
| Yosu Cadilla |
Not sure this is what worries you @Ruth Cheesley (she/her) but if 2.15.4 becomes a reality, then you don't really need to worry that much about speeding up M3 (or about providing a tranquilizing roadmap for the community) because you would be getting a few extra weeks or even months out of 2.x. (And you can announce Mautic 2.x is to be suppoerted for X more weeks/months and everyone will sleep better)In that case, adding necessary improvements to M3 when it most makes sense (now) is not such a delicate or urgent matter... |
| Yosu Cadilla |
As always, this would be an excellent point in time to poll the community and see what they want... |
| Yosu Cadilla |
And if you want to make things right and everyone in the community happy, it's simple, just add migrating all the existing PRs to 2.15.4 or 2.15.5. Beyond that you could ask Acquia to dedicate some resources to migrating any remaining code after a period of grace, if they broke it, it only makes sense they fix it too... |
| Yosu Cadilla |
Deprecating a working solution for another one that seems might be not up to par for a while is nonsense. |
| Yosu Cadilla |
Keep both branches alive for a few months! |
| john |
I was thinking about this a bit more. Maybe we don't need any problematic database migration at all. We use the bigint PR on our instances and we did not migrate our legacy instances. It's there so the new instances would be using the right ID columns type. We can say the same with the utf8mb4 update. It can be used for new instances but the existing instances will work the same. Well, except the doctrine:schema:update --force command will not work anymore as it will try to execute ID column changes that will not work because of foreign key constraints. |
| Ruth Cheesley (she/her) |
@dbhurley we discussed this in the last meeting and @norman made some suggestions of how we might proceed. See here: https://mautic.slack.com/archives/CQMKV0RU1/p1579000312019700We need clarification on how the product team will be working with you (and Acquia) to discuss the future roadmap and a process for putting together a first draft for comment.It would be nice if this could happen before or at the point of the M3 launch, to address the questions about ‘what next’ and about the open issues/PR’s and how they will be dealt with (we discussed this at the community summit, but it hasn’t been officially shared I don’t think).Can you give us any outlines or could we work in this meeting to start pulling together a draft? (edited) |
| dbhurley |
Yes, I've been working on this with Acquia people to see how this should be handled. I think I have a good idea and plan to start working with the product team here with what we the community want to see accomplished. |
| Ruth Cheesley (she/her) |
So, what are the next steps on this for the product team? |
| Ruth Cheesley (she/her) |
as @Yosu Cadilla mentioned, it would be good to both clarify what we’re going to do with people on 2.x who can’t upgrade right away (e.g. dependent on plugins which aren’t yet updated) and be clear on how long they have before we end support. I think there were discussions on this earlier in the week https://mautic.slack.com/archives/CQMKV0RU1/p1579528556000700 (edited) |
| Ruth Cheesley (she/her) |
Also in #mautic-3 https://mautic.slack.com/archives/CPVGZE516/p1579530466009600 (edited) |
| Ruth Cheesley (she/her) |
In addition to what happens in the 3.x branch longer term - release strategy and so forth. |
| dbhurley |
We will be planning a deprecation process for the 2.x series. We will release security patches as needed and until 3.x has been proven stable. Unfortunately due to our startup speed we moved too quickly to establish a proper STS/LTS release in the 2.x series. Moving forward we will be following that standard very closely (similar to Ubuntu, Joomla, and others) (edited) |
| dbhurley |
So while we might not be able to absolutely state the process for 2.x we will be sure to sunset it gracefully. |
| Ruth Cheesley (she/her) |
That sounds good, and presumably we need to work through the open PR’s against the current version (2.x). Some may need refactoring for 3.x, I presume? (edited) |
| jordan8037310 |
It would be great if there were some plans to provide documentation for Mautic 2.x to 3.x migration of plugins. I assume there are some resources and compatibility packages for Symfony 2.x to 3.x, so a document to reflect that would help the community move along. |
| Ruth Cheesley (she/her) |
@jordan8037310 that is already documented |
| Ruth Cheesley (she/her) |
Please take a look here: https://github.com/mautic/mautic/releases/tag/3.0.0-alpha for technical details |
| Ruth Cheesley (she/her) |
https://github.com/mautic/mautic/blob/a7c718da65a77f96f7745a680a202d713daac3e7/UPGRADE-3.0.md here’s the link for BC changes (edited) |
| Ruth Cheesley (she/her) |
My understanding is that this should be sufficient to help developers with updating their plugins/themes/etc to 3.x compatibility, but if it’s felt there is anything missing then definitely please let us know! |
| jordan8037310 |
I see the laundry list of changes. I am talking about recommendations for the process such as: https://symfony.com/doc/current/setup/bundles.html which more directly recommends https://github.com/symfony/phpunit-bridge as a method for detecting compatibility (edited) |
| Ruth Cheesley (she/her) |
Ah, so something a bit more descriptive as a step-by-step process you mean? |
| Ruth Cheesley (she/her) |
Definitely something the community could work up for inclusion in the developer documentation maybe? |
| Ruth Cheesley (she/her) |
the developer docs are on Github, so it’s just a case of making a PR for a new page. Would anybody be up for taking that on? |
| jordan8037310 |
Sufficient testing resources would help to drive forward the upgrade process. We could run tests against popular open source bundles and raise an issue with the itemized report, this would help create visibility on how much work was necessary to update such bundles and reduce the upgrade friction. |
| jordan8037310 |
Something that stages updates wouldn't be possible (we're not downloading a new package, we have to mark that a package needs to be created).Copying the output from phpunit-bridge and itemizing the TO DOs into a GitHub checklist will create visibility on the Mautic 3.x upgrade path for a given plugin bundle (edited) |
Ruth Cheesley (she/her), dbhurley, RGBguy, Yosu Cadilla, john, jordan8037310, kuzmany
Also note you can start a reply with 
to be anon, or 
to go off the record and not be included in the notes, which will be exported and saved to Google Docs, and posted on the Community Forums.The meeting will be open for 24 hours, after which the notes will be exported. People may comment thereafter but these won’t be included in the notes.Let’s get going! 