Replies: 2 comments
-
Sorry for the very late reply. And thanks for opening this discussion. It’s good to move this out of issues and pull request comments to a more central place. I totally agree with you with everything you mentioned. And I still feel what I said in #1863 (comment) applies.
As mentioned in #2407, I’m not sure we even need to switch to When I quickly looked at the changelog for twigphp/twig, I didn’t see anything alarming when we upgrade to a minimum of
I feel like tests only hold us back for now, also because it would be cool if we could switch to GitHub Actions and make the automated tests work again. You already put a lot of work into this and I would really like to see this fly. So the following steps would be required:
How do you feel about opening a pull request for this?
Heck yes, we also feel like it’s taking too long, but there are soo many things to consider, as you realized yourself. But I also feel like we should work toward releasing a stable 2.0 version. And then we should release newer versions with breaking changes more confidently. I know that @jared also feels like this. We don’t have to gather a lot of breaking changes for a version 3, but could also release them in versions 4, 5, etc. The
It doesn’t come over as criticism at all :). These are all valid concerns and you’re allowed to mention them. I myself would love to find more time, because I’m still very motivated to work on Timber. So thanks for understanding if some of us still put private life and not Open Source first. |
Beta Was this translation helpful? Give feedback.
-
Hi @gchtr, Thanks for your reply!
That would be a shame for many reasons.
I did indeed but it's also a backwards compatibility policy choice (you could choose to not have a backwards compatibility policy, at least not from 1.x). Timber has a lot of old code, some parts are still there with no one really knowing why 😅 . At the time it was designed, every method was public, there was a lot of public static properties, etc. IMO, deprecating each part of that old code is cumbersome and is, every all other legitimate reasons apart (private life, etc.), one of the reason things are moving slowly (it asks more work on code and docs). Considering no major update has been released since a long time and more importantly, now that Timber is a 100% PHP package (no more "click to update plugin" risk / people using composer should be aware that a major version can introduce breaking changes), I would be more in a "many things changed, read the docs and deal with it" mood 😄 I know you obviously don't share that point of view, you wouldn't work that hard to keep this v1 -> v2 transition that smooth 😉 So I'll deal with it and try to contribute when I can. |
Beta Was this translation helpful? Give feedback.
-
Hi Timber team,
I'd like to open a discussion on PHP/WP/Twig minimum requirements here because this is a topic that is mentioned is various issues/PR but isn't centralized somewhere.
Related: #2407 / #2349 (comment) / #1863 / #2339
Twig
Although
twig:^2.10
is the current Twig constraint in Timber, it actually doesn't pass tests (this is2.x
tested with GA).From @jarednova :
Problem:
twig/cache-extension
has atwig:^2.4
constraint and it would be a shame to release the brand new Timber 2.0 with an extension that's already not maintained anymore.PHP
I feel like the situation has really changed over the one/two last years. Requiring PHP
^7.4
is quite common these days. Package's developers don't bother supporting a wide range of PHP version anymore.Even WordPress is now pushing forward latest PHP version adoption ^^ And every decent hosting company makes the latest PHP versions available almost at the same time they are released.
Just like Twig, Timber 2.x actually doesn't pass tests on PHP 7.0 or 7.1. Requiring an up to date version would also simplify testing.
Upgrade policy
On a more global upgrade policy point of view, you are being very careful about backwards compatibility/not introducing BCs. This is nice for users who don't follow Timber feed like I do 😜
But I think it's holding a lot of things back. Timber has a lot of legacy code (I didn't realize it was that much before recently digging into it) and I feel like 2.0 is a great opportunity to introduce breaking changes/catch up with latest practices/requirements. An opportunity that doesn't happen that often considering Timber lifecycle (1.0 was released almost exactly 5 years ago!). I'm afraid too much
2.x future
labels will postpone important things too far in the future (2.x is already in the pipes for quite a time now).Don't get me wrong, this isn't in any way some hard criticism on your work/involvement/timeline on Timber's development. I'm fully aware of the hard work/time you put into it and the burden that maintaining OSS sometimes is. I also might not have all cards in hand to accurately evaluate your upgrade policy/decisions regarding breaking changes introduction, etc.
This just my humble opinion on this, opened for discussion obviously 😉
Wherever it leads, I think there's still an objective problem between stated support and actual support for those ones (I'll be working again on GA tests soon).
Beta Was this translation helpful? Give feedback.
All reactions