Move missing issue commits from 3.x to 4.x and clarify difference between 4.x and 3.x

That's actually it already! The 4.x branch was created back at the start of December 2024. I checked all 3.x commits from back then and almost all commits are already present in 4.x!

Please review @anybody!

@chi what was the reasoning for you back in december 2024 to create a new 4.x branch? What were the breaking changes you introduced, and why was there no release for 4.x?

@chi what was the reasoning for you back in December 2024 to create a new 4.x branch

Nothing special. It is just planned refactoring. The code in 3.x feels outdated. It does not use features from the latest versions of Drupal core and PHP. Note that even if a project is considered feature complete, you still need to occasionally create new major releases in order to drop deprecated code and bump requirements.

The project follows semantic versioning, which means BC breaks are only allowed in major releases.

Let's keep 3.x available for Drupal 10

3.x already supports Drupal 11. The common practice for contributed modules is to support two major Drupal versions.
For instance, if 3.x supports ^10.3 || ^11.0, then 4.x should support ^11.0 || ^12.0, and so on. In this approach, the 4.x branch is the main development branch, while 3.x is minimally supported. Development happens in the 4.x branch. 3.x only receives bug fixes and maintenance fixes, for example support for new PHP versions. The minimal minor version of Drupal core can be bumped later. If 11.0 is EOL, then we bump requirements to ^11.1 and so on.
Supporting multiple Drupal versions, even minor ones, is really hard. You will have to wrap your code in conditions like if (\version_compare(\Drupal::VERSION, '11.3.0-dev', '<')), especially in tests.

This way, consumers will not have to update Drupal core and the module simultaneously. For example, if some large project is upgrading to Drupal 11, they will first update all contributed modules. This approach is much safer than upgrading everything at once.

What were the breaking changes you introduced

Of course, I don't remember. :)

The best practice to prevent such issues would be maintaining CHANGELOG.md. See example from Date Point module.

I just pushed an AI generated document about the migration. It looks good to me, but needs manual review before publishing 4.x release.
https://git.drupalcode.org/project/twig_tweak/-/blob/4.x/docs/migration-...

why was there no release for 4.x?

Because refactoring was not complete and it was not urgent as 3.x supports the current Drupal version.

Having 4.x release at least beta is now more import as Drupal 12 is coming.

Thanks for the clearance @chi! I already saw, that the codebase of 4.x looks a lot more modern then the 3.x codebase, but since there wasn't a release I wasn't sure how stable it is (and what breaking changes where introduced). We'll create an alpha release first anyway so we should be safe.

Let's do it like this. 4.x will be ^11 || ^12 and 3.x will be ^10 || ^11.

I'd vote STRONGLY against this. This is a widely used module and I don't want to add support for a Drupal version that isn't fully tested yet (Drupal 12). Especially since the tests are currently all failing for Drupal 12 (phpunit (next major)).

Let's keep as is for now (4.x: ^11 and 3.x ^10 || ^11). We can add D12 support later on for 4.x.

Not much else here todo otherwise. Please review!

Right. No need to support Drupal Core version which does not exist yet. But we needs to be prepared which means 4.x should not use any deprecated APIs from Drupal Core.