Drop Support for Unsupported PHP Versions (BC Break)

[silasjoisten]

This PR drops support for PHP 7.4 and PHP 8.0, raising the minimum required PHP version to ^8.3. This change introduces a backward compatibility (BC) break, as projects running on older PHP versions will no longer be compatible.

I’d love to contribute more to this project!

My suggestion would be to create a 2.x branch where this PR could be targeted, maintaining backward compatibility for users on older PHP versions.

Additionally, I’d be excited to help with adding strict types to the library, ensuring even better code quality and reliability.

[timoisik]

Thanks for your contribution! Really appreciate the effort to modernize the library

However, I just looked into the Packagist stats. 38.6% of users are still on PHP 8.1 or 8.2. Additionally, PHP 8.1 receives security updates until December 2025 (per PHP's supported versions).

I appreciate the suggestion for a 2.x branch. but I’d like to keep maintenance as lightweight as possible and avoid maintaining two versions in parallel.

Would you be open to adjusting the PR to keep support for PHP 8.1+ for now?

[silasjoisten]

@timoisik thanks for your reply!

I completely understand the desire to keep maintenance lightweight, and I appreciate the consideration given to the user base still on PHP 8.1 and 8.2.

However, I’d like to expand on why I believe creating a 2.x branch would be beneficial:

• Security Fixes != Actively Supported: While PHP 8.1 will receive security updates until December 2025, it is already in its security-only phase. This effectively means it’s end-of-life (EOL) in terms of active development. Relying on an EOL PHP version for new library development limits our ability to adopt modern language features, which are key for improving performance, maintainability, and code quality.
• Future-Proofing the Library: The 2.x branch wouldn’t be something we’d rush to release. It could serve as a long-term development branch, giving us the flexibility to:
  • Introduce breaking changes gradually, like enforcing strict types throughout the library.
  • Refactor and rework parts of the codebase to improve architecture and developer experience.
  • Prepare for future PHP versions without being constrained by backward compatibility concerns.
• Clear Roadmap for Users: By maintaining a stable 1.x branch for PHP 8.1+ users, we ensure they continue to receive bug fixes and minor improvements. Meanwhile, 2.x can evolve independently, allowing us to innovate without disrupting existing projects.
• Reduced Technical Debt: Delaying breaking changes often leads to technical debt accumulating over time. Having a dedicated 2.x branch helps avoid this by providing a space to experiment and modernize without impacting stability for current users.

I’d love to continue contributing to this project and help with both maintaining the 1.x version and actively developing 2.x. Let me know your thoughts—I’m happy to adjust my PR accordingly or discuss a roadmap for 2.x if that’s an option.

[timoisik]

Hey @silasjoisten, thanks for your effort. While I agree with all your points, I don't want to apply them to this project (for now). As you see in the past we didn't had much time to maintain this package and I would rather provide missing features and fix issues for everyone than start rushing now without reason. I also want to avoid taking on additional maintenance overhead if contributors later step away.

Therefore I see the main priorities here as:

• Providing the features people would expect to have from Tiptap
• Keep dependencies updated
• Fix issues

Also I do agree on dropping support of PHP versions which don't get security updates anymore.

That said, I would be more than happy to see you as a regular contributor here.

[silasjoisten]

Hey @timoisik

Thanks for your thoughtful response—I really appreciate the perspective and completely understand the focus on keeping the library well-maintained without adding unnecessary overhead.

That being said, I’d love to contribute more actively and potentially help maintain the project in a more structured way. We have a strong need to bring it up to a modern PHP version to improve usability, and I see a lot of potential in evolving the library while still ensuring a stable experience for current users.

Would you be open to discussing this in more detail? I’d love to share my motives and ideas for how I could support the project long-term. Let me know if you’re available for a quick chat!