Bump "respect/stringifier" to version 2.0.0

[henriquemoody]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

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

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #1424   +/-   ##
=========================================
  Coverage     94.91%   94.91%           
  Complexity      981      981           
=========================================
  Files           195      195           
  Lines          2223     2223           
=========================================
  Hits           2110     2110           
  Misses          113      113           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[henriquemoody]

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

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

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]

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.