End-of-life, project status and Pico's future

[digitalinferno]

This isn’t a roadmap (Pico has been officially declared end-of-life), just a quick checkpoint for those still orbiting (like me) the Pico ecosystem.

Dependencies from the 3.0 dev branch:

"php": ">=7.2.5",
"ext-mbstring": "*",
"twig/twig": "^3.3.8",
"symfony/yaml" : "^5.4.3",
"erusev/parsedown": "1.7.4",
"erusev/parsedown-extra": "0.8.1"

I don’t have the skills to take over the project, but just for the sake of what if I try to upgrade something and see if the world is still out there, here we go. If you're experimenting, forking or sharing knowledge this could help shape your next steps, or maybe not.

• PHP 8.1 seems to work fine with the current codebase. Some cleanup might be needed, but nothing dramatic.
• Twig 3.x already requires PHP 8.1; upgrading to the latest 3.x version looks doable and mostly pain-free.
• Symfony YAML 5.4 (currently used) is still in extended support (only securety fixes) until 2029 thanks to a sponsorship. Eventually, jumping to 6.4 LTS would open more modern features and a newer horizon (active support until 2027), but it could also be a shot in the dark.
• Parsedown may be outdated (and for sure abandoned), but for now, it still gets the job done. Sometimes the old but gold mantra is exactly what you want.

Not so bad.

[PhrozenByte]

Thanks @digitalinferno for this summary 👍 I'll rename and pin this issue, it might be helpful for others to assess Pico's current state.

I just want to throw in a few notes (not just as a response to you, but some general notes) myself, too:

Referring to the README.md:

You can try the last v3.0.0-alpha.2 release, or use the pico-3.0 branch. They are as stable as the last "stable" releases, but just didn't make it through the release process before development was abandoned.

The only issue with #535 (i.e. the pico-3.0 branch) is that it didn't go through the release process, i.e. the code is ready, it's just that the changes are (partially) undocumented and that the code lacks (probably just some) testing. And the CI pipeline is broken. That's why PRs like #706 don't help much: Such PRs are basically just incomplete versions of #535 with the exact same issues. Pico is a well-established project, thus tagging a new major release (#706 would be a major release, too, because it includes basically the same breaking changes as #535) comes with a minimum guarantee of support (this also includes e.g. documentation) and testing.

Pico 3.0 currently just lacks this minimum guarantee of support and testing. That's why users with existing websites (i.e. a working setup) and developers (i.e. users that can fix issues on their own) can keep on using the pico-3.0 branch, including upgrading to it. That's totally fine, because we can assume that these users know what they are doing and thus don't need more documentation and testing than #535 already provides. There are no definitive reasons (like security issues) that would dictate switching to something else, so if existing users want to keep using Pico, they can. Such users simply don't need a tagged version for that.

It's just that things will break at some point in the future: The pico-3.0 branch should work fine with any PHP 8 release, even though it wasn't tested with PHP 8.2 and later. But since PHP rarely adds breaking changes with minor releases, it should remain possible to make Pico work with a loosened error_reporting. We'll see what happens with PHP 9, whenever its development starts.

Pico's history just repeats: Pico was in the same state 10 years ago, so I decided to take over the baton back then. I simply can't (nor want to tbh…) do that any more. So, if someone wants to take over the baton, I'm very happy to help with that. I agree that upgrading the dependencies again would be a good thing (thanks again for summarizing that, I absolutely agree with your assessment), but IMO that's really not the issue, it's what comes after that.

[digitalinferno]

Thanks again for your thoughtful and open reply, it's truly appreciated.

From your notes, it sounds like the current pico-3.0 branch is a solid foundation for anyone looking to experiment or potentially take the project further. At this point, I’m considering two possible paths, depending on whether there’s any community interest:

• If even a small group of people is interested, I’d be happy to explore the idea of a community-maintained branch, starting from pico-3.0. The goal would be modest: keep dependencies up to date, ensure compatibility with modern PHP versions, and document the existing features. Just enough to help current Pico users keep their projects alive a bit longer and perhaps pave the way for a new maintainer (or several) to eventually step in.

• If no such interest emerges and it turns into a more personal endeavor, then a soft fork (likely under a different name) might make more sense. In true open-source spirit, it would just be one variation among others and anyone would be welcome to build their own vision from it.

If anyone is curious or interested in participating, please do so!