Several changes did not make it in 3.2.2 (Bad merge?)

[DavidPrevot]

Some changes were reverted before the last release, and are not in the 3.x branch anymore. Simple examples:
4c72190 (Update LICENSE) and “Allow doctrine/lexer 2 by @derrabus in https://github.com/egulias/EmailValidator/pull/340”.

Regards

[derrabus]

Thanks. @egulias and I are already working on restoring those changes.

[sbuerk]

Also the utf8 en/decode removal (PHP8.2 deprecation) are missing in 3.2.2 -> f88dcf4

Just FYI. Thanks for taking care @derrabus

-> https://git.typo3.org/typo3/CI/cms/-/jobs/1847583/raw

[driesvints]

It seems after the 3.2.2 release quite a few of our package's test suites started to break with the "hello@example.com" email address:

https://github.com/laravel/telescope/actions/runs/3804233902/jobs/6471295811
https://github.com/laravel/framework/actions/runs/3804298612/jobs/6473840109

Any idea what change caused this?

[manuelkiessling]

@derrabus Please let us know if you need help from the community to collect all commits that went missing in action.

[driesvints]

The diff from 3.2.1 and 3.2.2 shows the changes which are the culprit for the issues here but I cannot seem to pinpoint the commits: 3.2.1...3.2.2

[manuelkiessling]

The diff from 3.2.1 and 3.2.2 shows the changes which are the culprit for the issues here but I cannot seem to pinpoint the commits: 3.2.1...3.2.2

Yeah it's super-weird and I start to actually question my understanding of how Git works - but there simply are no commits that e.g. revert the utf8_encode line, and yet it's gone. Also, CLI git log src/EmailLexer.php on current 3.x branch only shows commits up to 007bfd4 inclusive, omitting the 4 commits a5ed8d5, f88dcf4, 18b9e5b, and b28de87 that followed it. However, IntelliJ Git Log UI does show them (but their changes are nevertheless not in the file).

[manuelkiessling]

Same for 3.2.1...3.2.2 - the diff on the overview page shows the revert made to the utf8_encode line, but if you open all 15 commits that are listed as part of the changeset one-by-one, none of them has that change.

[driesvints]

@manuelkiessling most likely the changes are pulled in from the merges that happened.

[manuelkiessling]

@driesvints Yeah, but the (GitHub?) view is definitely off (or my understanding of it). For example, IntelliJ shows merge commit ecbcdce as the culprit for re-introducing the utf8_encode call, but ecbcdce says Showing 0 changed files with 0 additions and 0 deletions..

[egulias]

Hi folks, I'll be looking into this, I'm dealing with some unexpected family stuff (all good, but logistics got upset), so I'm not having the time I expected to have.

Apologies for the inconvenience.

[driesvints]

@egulias no worries. These things happen 👍

[egulias]

I'm a bit rusted on this, but, here's one option

1. we could make tag 3.2.2 point to 0170967 , which is just before Allow doctrine/lexer 2 #340 merge
2. Rebase/recreate 3.x ignoring Allow doctrine/lexer 2 #340
3. Merge Allow doctrine/lexer 2 #345 and tag 3.2.3

WDTY?

[driesvints]

Yeah that seems best to me 👍

[derrabus]

I would advise against changing an existing tag.

If you're short on time, create a new tag 3.2.3 right before the broken merge. That buys us some time and we can release 3.2.4 as soon as we've fixed everything.

[driesvints]

Also, a PHP 8.1 & 8.2 build could help catch some of these errors.