Textpattern's ongoing development

Bloke · 2025-12-24 22:30:45

Now we’ve (finally) shipped Textpattern 4.9.0, and I hope it serves everybody well, the aim is to continue to push minor changes to the branch to fix bugs/features and support PHP/MySQL advancements, but this officially ends the Textpattern 4.x series.

It’s been at level 4 for around 20 years, and it’s time to move things on to bigger and brighter things. To build on the foundations we’ve laid, with the principles and ideals of its creator Dean Allen still beating at its heart, and push our favourite CMS into greater pastures. We’ve already made great strides towards Textpattern 5.0.0 in the custom-fields branch and stuff is evolving there at pace. I don’t think it’s too boastful to say that the work we’ve put in so far has not been attempted by anyone in any major CMS, and is the cornerstone of what will become insanely powerful yet familiar to everyone who has grown to love the platform, as well as a welcoming environment to new people who want something blazingly fast, nimble and flexible to power their online presence.

We still have a lot of consolidation to do in the wake of 4.9.0: docs, feature articles, server restructuring, translation, evangelism (which we would please encourage each and every one of you to assist by making as much positive noise as you can about the CMS), and so forth. But we will soon be switching the development branches so that 5.0.0 takes centre stage and 4.9.x is kept up-to-date for support purposes only.

I have every confidence in the team of amazing volunteers, hobbyists, testers, coders, administrators, designers, and lovers of the written word that continue to work with, on and around this amazing project. Thank you so much for sticking with it, or even finding us and staying for the ride. Textpattern means so much to me – its community and spirit especially – and I’m proud of what we’ve achieved and what we can achieve going forward.

For those that celebrate this time of year, wherever you are in the world, I hope you have a fantastic break and we’ll be back in the new year to forge ahead with the next phase in development.

Merry Christmas and a Happy New Year.

phiw13 · 2025-12-24 23:29:04

Have a nice year-end holiday, Stef, and thank you for the ongoing work on that little CMS that does big.

Onwards to the next year!

spiridon · 2025-12-28 09:07:56

Thank you, guys, for this gem you’ve created and polished!

Wishing you good health and happiness!

Bloke · 2026-01-11 16:48:44

Okay, the overview mentioned in the OP is now done. Branches:

dev: Textpattern 5.0.0 ONLY – EXPERIMENTAL: CURRENTLY NOT FOR PRODUCTION ENVIRONMENTS
~~@v4.9.1@~~ 4.9.0: Bug fixes to the 4.9.x branch ONLY (pull/clone this branch if you’re testing new features).
custom-fields: defunct. Now in dev. Will be deleted in due course.

Edit by gaekwad: renamed big fix branch – please see subsequent posts in this thread for background.

Last edited by gaekwad (2026-01-12 15:28:24)

Bloke · 2026-01-11 16:52:28

P.S. The demo sites might be a bit wonky for a while, because, like an idiot, I forgot to forewarn Pete.

I am such a dunce. Sorry sorry sorry sorry sorry sorry sorry sorry sorry sorry sorry sorry…

gaekwad · 2026-01-11 18:44:46

Bloke wrote #342157:

P.S. The demo sites might be a bit wonky for a while

Engineer on-site. Don’t worry.

gaekwad · 2026-01-11 18:47:31

Bloke wrote #342156:

v4.9.1: Bug fixes to the 4.9.x branch ONLY (pull/clone this branch if you’re testing new features).

Presumably if we need multiple 4.9 patch releases over the coming years, this non-dev branch name will be changed? Could we consider calling the non-dev branch something that’s fixed and indicates the maintenance branch, but doesn’t indicate a release number?

Edit: de-Textile’d.

Last edited by gaekwad (2026-01-11 19:59:15)

gaekwad · 2026-01-11 18:53:41

We also need to consider new branches for pophelp and textpacks for v5 as we already have v5-only strings that don’t need to clutter up the current v4 branches, and we can trim back any v4 cruft that doesn’t make it v5.

Shall I open new issues, Bloke?

Bloke · 2026-01-11 19:12:10

gaekwad wrote #342162:

Could we consider calling the non-@dev@ branch something that’s fixed and indicates the maintenance branch, but doesn’t indicate a release number?

Sure. Rename it 4.9.x?

Bloke · 2026-01-11 19:13:11

gaekwad wrote #342163:

We also need to consider new branches for pophelp and textpacks for v5. Shall I open new issues, Bloke?

Yes please.

gaekwad · 2026-01-11 20:19:29

Bloke wrote #342166:

Sure. Rename it 4.9.x?

Something along those lines, yes. We’re not going to have a 4.10 since v4 is in patch-only mode, so calling it 4.9.x or 4.9 also gives a maintenance path when v5 lands with backwards incompatible changes. It’s not unfeasible to expect production sites to want to wait to upgrade to v5, and that might include a round or two of annual PHP releases.

Scenario: let’s say we release v5.0.0 in winter 2028, and we’re up to v4.9.4 (e.g. v4.9.1 for bug fixes; v4.9.2 for PHP 8.6 + MySQL 9.7; v4.9.3 for the 2027 release of PHP; v4.9.4 for the 2028 releases of PHP + MySQL). We might have to consider another one or two cycles of PHP support (e.g. Textpattern v4.9.5 and v4.9.6) since Textpattern v5 will have backwards incompatible changes, and we don’t really have much insight into the upgrade cadence of production sites (aside from knowing that some are still on v4.6…see this recent RPC thread).

So, yes – calling it 4.9.x or something similar makes it clear of its purpose, and doesn’t obviously clobber us for the next few years.

gaekwad · 2026-01-11 21:44:20

gaekwad wrote #342163:

We also need to consider new branches for pophelp and textpacks for v5 as we already have v5-only strings that don’t need to clutter up the current v4 branches, and we can trim back any v4 cruft that doesn’t make it v5.

This should also be considered for the other project repos, too – themes, docs (which is a whole other thing that needs unpacked), and toolbelt scripts off the top of my head.

gaekwad · 2026-01-11 21:46:09

wet wrote #342171:

One might also consider the usance of *ix people calling one of their releases LTS.

+1.

Bloke · 2026-01-11 22:05:23

gaekwad wrote #342169:

calling it 4.9.x or something similar makes it clear of its purpose.

Makes sense. I was thinking each rev would get its own branch and we’d delete the old one but, for continuity sake and less faff with scripts, you’re right that it makes sense to use a generic name.

Anyone fancy taking a stab at renaming a branch can do so from GitHub, but that has ramifications for people whom have cloned already when syncing, as outlined in the link above.

So maybe the better option is to do it at the command line:

git checkout v4.9.1
git pull
git branch 4.9.x
(change any file superficially like History.txt)
git commit
git push -u origin 4.9.x
git branch -D v4.9.1
git push origin --delete v4.9.1

Something like that ought to do it.

Bloke · 2026-01-11 22:10:53

gaekwad wrote #342172:

This should also be considered for the other project repos, too – themes, docs (which is a whole other thing that needs unpacked), and toolbelt scripts off the top of my head.

Yes. Let’s make 4.9.x branches for all these projects too.

The checksums toolbelt script for the new 5.0.0 dev needs to reflect the change to TXPINTERFACE, for example. There will be others.

Textpattern CMS support forum

#1 2025-12-24 22:30:45