Some changes were reverted before the last release, and are not in the 3.x branch anym

Thanks. <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Several changes did not make it in 3.2.2 (Bad merge?),about egulias/emailvalidator

egulias commented on June 3, 2024 2

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.

from emailvalidator.

derrabus commented on June 3, 2024 2

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.

from emailvalidator.

egulias commented on June 3, 2024 2

3.2.4 released

from emailvalidator.

derrabus commented on June 3, 2024 1

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

from emailvalidator.

driesvints commented on June 3, 2024 1

@egulias no worries. These things happen 👍

from emailvalidator.

driesvints commented on June 3, 2024 1

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

from emailvalidator.

egulias commented on June 3, 2024 1

3.2.3 created https://github.com/egulias/EmailValidator/releases/tag/3.2.3

from emailvalidator.

manuelkiessling commented on June 3, 2024 1

Not that anyone asked, but fyi: After upgrading to 3.2.3 in my Symfony project, all of my tests are still green and the PHP 8.2 deprecation warnings for utf8_encode are gone.

from emailvalidator.

sbuerk commented on June 3, 2024

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

from emailvalidator.

driesvints commented on June 3, 2024

It seems after the 3.2.2 release quite a few of our package's test suites started to break with the "[email protected]" 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?

from emailvalidator.

manuelkiessling commented on June 3, 2024

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

from emailvalidator.

driesvints commented on June 3, 2024

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

from emailvalidator.

manuelkiessling commented on June 3, 2024

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).

from emailvalidator.

manuelkiessling commented on June 3, 2024

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.

from emailvalidator.

driesvints commented on June 3, 2024

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

from emailvalidator.

manuelkiessling commented on June 3, 2024

@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..

from emailvalidator.

egulias commented on June 3, 2024

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

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

WDTY?

from emailvalidator.

driesvints commented on June 3, 2024

Yeah that seems best to me 👍

from emailvalidator.

egulias commented on June 3, 2024

Ok, lets "run forward" then.

from emailvalidator.

egulias commented on June 3, 2024

Ok, now to the bad merge.

from emailvalidator.

egulias commented on June 3, 2024

I believe we all assumed that would be the outcome, thanks for checking and sharing!

from emailvalidator.

egulias commented on June 3, 2024

This is so weird...
If I checkout to 3.2.3 and bring #345 into it... here are the changes GIT says there are, while github is just showing 6 file changes from @derrabus

And there is where everything brakes. For some reason these are changes from 2 years ago... like PHP 7.3 in Travis matrix

from emailvalidator.

egulias commented on June 3, 2024

So looks like I cannot safely merge #345 (or #340 for that matter), Github is hiding the real diff (for whatever reason).
@derrabus I can create a branch from 3.2.3 and we start from scratch? And then merge into 3.x said branch, my thinking is that it should revert those changes.
We could take the chance to bring in @driesvints suggestion of adding PHP 8.1 and 8.2 into Travis' matrix for 3.x

from emailvalidator.

driesvints commented on June 3, 2024

@egulias if you want I can take some time to set up a GitHub Actions workflow for you?

from emailvalidator.

derrabus commented on June 3, 2024

We could do a hard reset of the 3.x branch to the new 3.2.3 tag which should remove the broken merges from its history.

git switch 3.x
git reset --hard 3.2.3
git push -f

You might need to temporarily disable GitHub's branch protection to allow the force-push.

This would leave 3.2.2 intact although it would point to a commit that's on no branch.

from emailvalidator.

derrabus commented on June 3, 2024

Also, I believe @driesvints' suggestion to build the CI in GitHub Actions is a good idea. The current Travis setup seems a bit broken and unreliable and it might be easier to recreate it in GHA than to fix the Travis setup.

from emailvalidator.

egulias commented on June 3, 2024

Yeah, Travis has become less reliable with time since they were bought.
Ok, lets go step by step.
I'll reset 3.x, merge your changes and release 3.2.4
@driesvints yes please, I'd appreciate the GHA setup, I'll have to learn about it.

from emailvalidator.

egulias commented on June 3, 2024

reset done.

from emailvalidator.

egulias commented on June 3, 2024

All right. @derrabus , check #345 , there is now a 68 files diff. Somethig's odd with your branch maybe? Can you close and PR again?

from emailvalidator.

derrabus commented on June 3, 2024

Since you've removed the broken merges from 3.x, my PR would add them back. That's the commits you're seeing now. I'll rebase the PR.

from emailvalidator.

driesvints commented on June 3, 2024

I sent in a GHA build for this library: #348

from emailvalidator.

derrabus commented on June 3, 2024

Thanks a lot!

Now since the 4.x branch also contains these broken commits, you probably want to reset that one as well:

git switch 3.x
git pull
git switch 4.x
git reset --hard 3.x
git push -f

from emailvalidator.

egulias commented on June 3, 2024

Fixed.

from emailvalidator.

Several changes did not make it in 3.2.2 (Bad merge?) about emailvalidator HOT 33 CLOSED

Comments (33)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent