Roadmap to 2.3

[alganet]

To get a release candidate 2.3RC:

• Drop PHP 7.4 support
• Increase phpstan level from 7 to 8 and remove non-false-positive error ignores
• Remove obsolete dev-dependencies and suggests
• Ensure auto-updater bots for regional data are 100% working
• Answer all most issues and opened PRs, provide fix for all real bugs reported.

To get a stable release 2.3.0:

• Comment on issues that will be addressed in future releases or require more discussion
• More integration tests for oneOf, allOf and each validator messages.
• Document support, release schedule and voluntary backporting guidelines.
• Increase code coverage from 96% to 98%
• Get my credentials for @TheRespectPanda accounts in order
• Extra documentation for most common support issues
  • Message translation approaches
  • Navigating the messages tree manually
  • Using validators with custom names
  • Expressing boolean algebra

List of fixed issues for the this release

Tentative RC release date: 2023-03-01
Tentative stable release date: 2023-03-15

[alganet]

If everything goes well, we'll release the RC tomorrow and close a lot of the issues marked as Next Release.

I moved some of the less non-implementation stuff to the final release date.

Hopefully, we'll have only one RC and not RC2 and etc. If you find anything unusual with the release candidate, you can use this issue to report it in a less formal way (or you can open a new issue, you can always do that 🐼 )

[alganet]

Release candidate 2.3.0-RC is out!

https://packagist.org/packages/respect/validation#2.3.0-RC

[andus4n]

hello. any news on the final 2.3 version?

[alganet]

Hi @andus4n, very few people tried the 2.3RC, so I'm giving it a little more time for us to find possible issues before launching it. The original idea was to release Match 15th, maybe we'll do it on April 15th!

[oschwald]

After seeing the above, I tested it out on maxmind/minfraud. Besides some minor exception text changes, I did notice an issue with 2014-04-12T23:20:50Z no longer being accepted as a valid RFC 3339 timestamp in this rule. This works fine on 2.2.4.

[alganet]

@oschwald thanks for reporting this! I will look into it and get back to you soon.

[andus4n]

hi. any news?

[henriquemoody]

I'm sorry, @alganet!

I completely overlooked this issue... 😅 The excellent news is that I released the 2.3 version!

I've become less conservative about tidying up a version too much before releasing it.

Maintaining an open-source project takes a lot of work. Over the years, there have been peaks of work from you and me, but keeping it consistent takes time and effort. That said, I'd rather enjoy those peaks and deliver value as soon as possible rather than make it perfect, which makes it harder for me and delays delivering value.

What would you like to do with this issue?

[andus4n]

@henriquemoody, i noticed you renamed the "attribute" rule to "property"...this is a very bad move since i have literally thousands of entries for the old name.
can you keep "attribute" as an alias for "property"?
thx.

[henriquemoody]

@andus4n, that is on master, not on any stable version. I will consider creating an alias with attribute, although that would depend on whether I can create an "Attribute" rule. I've wanted to allow Validation to validate properties using PHP attributes for a while.

In your case, wouldn't it be possible to replace those entries? If you're using it via v:: and don't have any more method in your application that's called "property" you will be able to replace them with a single command-line:

rg '(v::|->)attribute\(' -l | xargs sed -Ei 's,(v::|->)attribute\(,\1property(,g'

Then if you want to be safe which changes you would like to have or not you can always use git add -p to select the ones that work well for you.

[andus4n]

@henriquemoody, i will use sed to replace the entries...but this is a major breaking change if you decide to release it (attribute is one of the most used rules). keep up the good work, this library's awesome.

[henriquemoody]

@andus4n, you will be pleased to know that I've created a way to keep the behaviour of the attribute rule despite renaming it!

You can see the tests I've written here: https://github.com/Respect/Validation/blob/main/tests/integration/rules/deprecated/attribute.phpt

It will trigger an E_USER_DEPRECATED error but will continue working -- you can suppress that with error_reporting(E_ALL & ~E_USER_DEPRECATED). Even if I create another attribute rule, I can still keep the behaviour of the old one!

[henriquemoody]

I will close this one since version 2.3 was released.

Once again, I'm sorry I didn't see that before releasing the version, @alganet 😞