search

Respect / Validation

The most awesome validation engine ever created for PHP
https://respect-validation.readthedocs.io
MIT License
5.75k stars 774 forks source link

Bump "respect/stringifier" to version 2.0.0 #1424

Closed henriquemoody closed 5 months ago

codecov[bot] commented 1 year ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (12c1457) 94.91% compared to head (4c33f08) 94.91%.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #1424 +/- ## ========================================= Coverage 94.91% 94.91% Complexity 981 981 ========================================= Files 195 195 Lines 2223 2223 ========================================= Hits 2110 2110 Misses 113 113 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

henriquemoody commented 1 year ago

@alganet , there are a few more things that I'd like to contribute to (upgrade PHPUnit for example), but without dropping support for PHP 8.0 I can't. However, contributing on master is very tricky, because 2.3 is growing on a different branch.

What should I do?

alganet commented 1 year ago

@henriquemoody sorry for the delay in answering this!

I'm conflicted about working on multiple branches myself. I wasn't expecting more people to jump in this new cycle.

My goal was to stop working on the 1.x and 2.2.x series, effectively making the 2.3.x series the only version being worked. I need to formalize that better (maybe delete the other branches, update some docs).

I was updating master with the 2.3 contents periodically, so people looking at the code would see the recent changes. I was approaching them as the same thing (master == 2.3).

Your changes and PHP 8.0 drop though ask for a 2.4, so I guess we can open a branch for that?

I know you dealt with this multi-branch thing in the past, so your opinion might be more relevant than mine here, please feel free to share what you think the best approach may be.

henriquemoody commented 1 year ago

When I was maintaining the library, I used to avoid creating branches for versions that haven't been released yet. The advantages of having a branch for an existing version is that we can create patches for that specific version. Creating branches for upcoming versions gave me lots of headaches.

When it comes to new versions, my favorite approach was having master (which we should probably rename to main soon), lead. Once you're ready to release a new version, then you create a branch, push it, create a tag, push the tag, and voilà.

At some point, I stopped caring about avoiding creating MAJOR versions. For a long time, I only wanted to create a MAJOR for something super revolutionary, but that was also on the way of progressing the library. As Sebastian Bergmann once told me in a pull request: a version is just a number.

From my perspective, the best is having master lead the next version, create branches only for existing versions, and not being too conservative about creating MAJOR versions.

henriquemoody commented 5 months ago

Hey, @alganet!

I assumed you took a break from Validation, so I went ahead and made changes to it. A lot of changes... I mean, a lot... I hope that's okay with you, but if it's not, we can always revert stuff.