New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support sabre/xml v4 #607
Support sabre/xml v4 #607
Conversation
Codecov Report
@@ Coverage Diff @@
## 4.5 #607 +/- ##
============================================
+ Coverage 98.35% 98.57% +0.22%
Complexity 1897 1897
============================================
Files 71 71
Lines 4548 5483 +935
============================================
+ Hits 4473 5405 +932
- Misses 75 78 +3
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Alternatively I think we could release 4.5.1 as 4.5.3 again. Then we could use 4.5.2 and publish it as a new major. |
The changes here look fine if you prefer it |
9a857cd
to
d672f6c
Compare
d672f6c
to
bad63c0
Compare
Do you think that the If I just re=release 4.5.1 as 4.5.3 then the ability to use If I do this PR, then @gharlan (and others) can have the latest |
I don't have a strong opinion which way to go from here |
I accidentally released 4.5.2 on Friday with all the code in
master
branch. That code has various PHP 7.4-only things that will not work properly on PHP 7.1 7.2 7.3 etc.See comment #588 (comment) which reports this mistake.
This PR:
If I merge this and then release 4.5.3 from the 4.5 branch, I think that it should be fine.
The added return types are all supported from PHP 7.1 upward, so that is nice.
The only thought that I have now is that if consumers have implemented child classes that redeclare
xmlSerialize
orxmlDeserialize
then maybe they will also have to add a return typevoid
orarray
? And so that will mean that the release is not strictly backward-compatible. And so a patch release is not correct.Thoughts please @staabm @DeepDiver1975 or anyone.