Joomla 6.0 shipped on the 14th of October 2025, the culmination of about a year's work by Gary Barclay and me as its release managers. We then carried on as caretakers of the 6.0 line for another six months, until Harald Leithner and Stefan Wendhausen shipped Joomla 6.1 on the 14th of April 2026. That was the moment our term came to its natural close.

So I am writing this as a former release manager, a month out of the role and with the dust beginning to settle. The work was rewarding, the people were remarkable, and the privilege was real. This is a thank-you note dressed up as a lessons-learned piece. If anything I write here helps future release managers settle in faster, or helps the community get more out of the release managers, then it has done its job.

It is not about your code

The single biggest surprise for me was how little of the work involves writing code. I came into the role with a developer's mindset, expecting to spend my evenings buried in pull requests of my own. In practice, the release manager's job is to encourage others to code, to review the work that is offered, to chase the bits that have stalled, and to keep a conversation moving across timezones and GitHub comments.

If you measure your contribution by lines of code committed, you will feel like the impostor in the room for most of your term. Measure it instead by the work you have unblocked, the contributors you have kept engaged, and the pull requests you have helped land. That is where the value sits, and that is the shift in mindset that no one tells you about on day one.

But it is also about learning to disappoint. You are the transient guardians of Joomla's codebase, and with that you have to learn to say no to a lot of people with good intentions, people who want to expand the code base and make things easier. But the codebase is for the majority, and minority requests can make it cumbersome for the many even if better for the few.

There is a mountain to learn before day one

A new release manager arrives with a developer's knowledge of Joomla and a vague sense of how releases work. What is actually required is a working understanding of the release lifecycle, the package signing process (TUF and all), the maintainers' workflows, the marketing team's needs, the security team's protocols, the documentation team's deadlines, the weekly meeting cadence, and the unwritten rules about what it is acceptable to merge late and what it is not.

It also becomes clear that alphas are ignored. Not by everyone, but by many, including extension developers, and this is a shame. The alpha cycle is a great opportunity to check and assess your code, and to keep up with the progression of change rather than leave it all to the last minute.

Almost none of this is captured in a single document. Most of it lives in the heads of the people who have done the job before. You will pick it up; you have no choice. But you will pick it up while the clock is ticking on a real release with real users waiting at the other end, and that is not a comfortable place to be learning.

The best release managers are probably former release managers

Which leads to the most important point I want to make in this article. The people best suited to be release manager are the people who have already been release manager. The knowledge sits with them, the muscle memory sits with them, and the lessons learnt are ingrained in them.

That makes a former release manager a precious community resource, not a retired one. They should be on hand to mentor, to advise, and to back up. Joomla has been good about this in spirit: Harald Leithner has been a quiet presence behind multiple releases and was back in a formal role for 6.1. 

Benjamin Trenkle has been behind many releases and has also changed and improved the release process along the way. Martin Kopp is back after a mammoth previous stint as release manager. That kind of continuity is exactly what the project needs more of, and we should be building it in deliberately rather than relying on willing volunteers happening to stick around.

The case for shadowing

Picture this. Every release manager, in the months before their own term begins, sits in on the meetings of the current pair. Not as a release manager, but as an observer. They watch how the weekly maintainers' meeting runs. They see how a contentious pull request gets discussed. They feel the cadence of the chat in the maintainers' channel. They see what a release manager actually does on the day a security advisory lands.

By the time their own term begins, they have a feel for the rhythm of the work. They know who tends to weigh in on what. They know how decisions actually get made, as opposed to how the documentation says they get made. They have absorbed the ethos.

I would have benefited enormously from that. By the time I had picked up the rhythm myself, my term was already past the halfway mark. Future novice release managers deserve a smoother on-ramp, and the community has the people in place to give them one.

Please come and have a conversation

A quieter lesson, but one that genuinely surprised me, is how little the community used the access it actually had to us.

Many people had ideas for Joomla 6. Many people had opinions about Joomla 6. Articles were written. Posts appeared. Comments turned up in places I would have to go and find them. And yet very few of those people contacted Gary or me directly to talk about what they wanted.

This is despite Gary and I being featured in this magazine as release managers, despite us writing articles of our own, and despite both of us turning up at Joomla London every single month. The channels were not hidden. The doors were not locked.

It felt, at times, like being shouted at from across the room rather than having someone wander over and start a conversation. The shouted version is much less useful, to everyone involved. A five-minute chat at a meetup, or a short message in the right channel, will get your idea further than a hundred-word forum post that the release manager may never see.

This matters more than it might sound, because the window is narrow. The time to talk to release managers is in the run-up to a release, not after it. Once a version ships, the job becomes maintenance, and the door for new code is closed until the next cycle.

Joomla 6.0 and 6.1 are both out. New features will not be going into either of them now. The version that is still being built is Joomla 6.2, and the people building it are Charvi Mehra and Martin Kopp. Alphas and betas are in flight, and that is precisely the moment when new code, new ideas, and new features can still land. Come October, when 6.2 ships, the door closes again.

If you have an idea for Joomla 6.2, please do reach out to Charvi and Martin directly. They want to hear from you. The Joomla roadmap lays out the release cycle and the current pair, and it is worth a bookmark for anyone who cares which version their idea might land in.

Trust your fellow manager

I have a huge debt of gratitude and it's owed to Gary who was an amazing release manager. We have had some right royal ding dongs over the years, working on client projects and with Joomla London, and although I was always right I have to admit that about 50% of the time so was he. It takes time to learn how to listen to the other side, the other view, and to present your points in a constructive way. The job is not to beat your fellow manager into submission, but together to synthesise something better than the parts, and that takes time and patience. Patience to learn the others point of view and appreciate that what they are saying is for the betterment of Joomla, of the release.
I think the process has helped us to understand and appreciate the other more, and that's a valuable outcome. 

The maintainers' team is phenomenal

The last thing I want to put on the record is the work of the maintainers' team.

Before this role I knew the maintainers existed. I knew they reviewed pull requests. I had no real sense of the volume, the consistency, or the standard of the work. The weekly meetings to triage specific pull requests are only one slice of it. The maintainers' channel is busy with discussion all day, every day, on details that most users will never see and that exist for no reward other than the satisfaction of getting it right.

The release manager sees this from the inside. The community deserves to see more of it from the outside.

If you use Joomla, you owe a great deal to a group of people who are not paid, are rarely thanked, and who do the work anyway. The next time a release ships smoothly, that is what you are seeing the result of.

Over to the next pair

To Charvi and Martin: thank you for taking it on. You will be brilliant, and the community is in good hands.

To the rest of us: turn up, engage, and say hello to your release managers. They are not as far away as it might feel.