Changelog History
Page 2
-
v2.0.8
May 20, 2020 -
v2.0.7
May 19, 2020 -
v2.0.6
May 18, 2020 -
v2.0.5
May 18, 2020 -
v2.0.4
May 18, 2020 -
v2.0.3
May 13, 2020 -
v2.0.1
April 14, 2020 -
v2.0.0 Changes
April 04, 2020The Respect development team announces the immediate availability of Respect\Validation 2.0.0.
🚀 This release adds nineteen new rules, improvements, and bug fixes.
This version is been in the master branch for a long time, it’s not perfect, but it is good enough.
Acknowledgment
🚀 We would like to thanks to all the developers who spent their free time to contribute to this project. Without you, this release would be impossible. Especially:
- 🚀 Danilo Correa (@danilosilva87), for grabbing the bull by the horns and applying the new contribution guidelines to 36 rules, and for always asking how he could help to make the release go earlier.
- 🚀 Emmerson Siqueira (@batusa), for applying the new contribution guidelines to a few rules, reviewing code, managing issues, and challenging the ideas in this release.
- William Espindola (@williamespindola), for applying the new contribution guidelines to 21 rules, and also doing code review, managing issues.
- Danilo Benevides (@DaniloBenevides), for applying the new contribution guidelines to 16 rules.
♻️ Also, Jetbrains for providing a License that allowed me to refactor a lot faster using PHPStorm.
🆕 New rules
- ✅ Create Base64 rule (Kudos to @jenssegers)
- ✅ Create ContainsAny rule (Kudos to @dlussky)
- ✅ Create Equivalent rule (Kudos to @henriquemoody)
- ✅ Create GreaterThan rule (Kudos to @henriquemoody)
- ✅ Create Iban rule (Kudos to @mazentouati)
- ✅ Create Isbn rule (Kudos to @frommMoritz)
- ✅ Create LessThan rule (Kudos to @henriquemoody)
- ✅ Create Luhn rule (Kudos to @mazanax)
- ✅ Create MaxAge rule (Kudos to @henriquemoody)
- ✅ Create Nif rule (Kudos to @juliangut)
- ✅ Create Nip rule (Kudos to @regdos)
- ✅ Create NotEmoji rule (Kudos to @mazentouati)
- ✅ Create Nullable rule (Kudos to @jenssegers)
- ✅ Create Number rule (Kudos to @iamraccoon)
- ✅ Create Pis rule (Kudos to @koga187)
- ✅ Create StringVal rule (Kudos to @henriquemoody)
- ✅ Create Subset rule (Kudos to @Singwai)
- ✅ Create Time rule (Kudos to @henriquemoody)
- ✅ Create Unique rule (Kudos to @gronostajo)
- ✅ Create Uuid rule (Kudos to @vdhicts)
🆕 New features
- 👻 Array with exception messages
- 👌 Improve support for translation
- Customize stringier
- 👻 Custom exception namespace
- 👻 No need to create one exception per rule
- Increase granularity control of Not rule
👍 PHP support
- ⬇️ Drops support for PHP < 7.2
Backwards Compatibility Breaks
🚀 This version (2.0) has more than 8k backward compatibility breaks 1 with the last version (1.1). Most of them, are all the classes becoming final and public properties becoming private, but there are some other big ones. All those backward compatibility breaks help Validation to be easier to maintain, allowing us to release more and more often.
Below a more detailed list of the main backward compatibility breaks:
Almost all classes are final
There are many reasons why classes should be final 2. Most classes we have are self-contained, and there are not many cases that inheritance is necessary. We want to encourage users to use them to use composition rather than inheritance, especially if we are talking about the rules, and for that same reason, we are also focusing on making their APIs clearer.
No more public properties
Public properties are one of the enemies of maintainability because they make the objects mutable and unpredictable. With them, we cannot ensure an object has a valid state, and we need to validate the properties before using them. Besides, changing a property name is a background compatibility break.
PHP 7 type-hinting
In this version, the whole codebase uses PHP 7.1 type-hinting. They are also using strict typing.
Methods assert() and check() do not return values
👻 In the last versions, those methods were supposed to return a boolean value or throw an exception. However, in practice, those methods throw an exception when the validation fails and return TRUE when the validation passes.
👻 In this version, those methods don't return any value: when it throws an exception it means that the validation failed; when they don't throw an exception it means that the validation passed.
🚚 NestedValidationException::findMessages() was removed
After trying to fix its behavior many times, it was clear that the method itself was very confusing. Also, it became unnecessary due to how Validation evolved during the development of version 2.0.
In older versions, that method is mainly used to translate, customize templates, and retrieve the messages in an array structure.
🔧 In this version, users can configure a global translator in the Factory. As for the customization and to retrieve the messages in an array structure, users can use "NestedValidationException::getMessages()" that does a much better job.
🚧 Because of the reasons mentioned above, and for the fact that "NestedValidationException::findMessages()" is so high maintenance as a consequence of all its edge cases, it made sense to remove it from the codebase.
Rules cannot be overwritten
In the previous versions, user could overwrite Validation rules using with(), not they can’t./
OneOf rule has different behavior
✅ In the last version, the OneOf rule validation passes if any assigned rule validation passes. In this version, the OneOf rule validation pass if only one of the assigned rule validation passes.
✅ We also created the AnyOf rule in which the validation passes if any assigned rule validation passes.
Date rule has different behavior
✅ In the last version, the Date rule validation passes if the input is a date, time, or date and time. However, it does not provide a way to be specific about the validation of date or time.
✅ In this version, the Date rule validation passes only if the input is a date. We also created a Time rule to validate time, and a DateTime rule to validate date and time (as Date used to be).
Min, Max, and Between rule have different behavior
✅ In the last version, Min, Max, and Between allow users to define whether the validation is inclusive or exclusive with a boolean value in their constructor. Those boolean values not made the complexity or those rules higher, but also confusing sometimes.
✅ In this version, the validation of those rules is always inclusive, and to use Between you need it is necessary to provide both minimum and maximum values. To help with non-inclusive validation we created LessThan and GreaterThan rules.
Each rule has different behavior
✅ In this version, the Each rule can validate both keys and values of the input. In this version, the Each rule can only validate the values of the input.
Some rules were renamed
- ✅ Cntrl is now Control
- ✅ Iterable is now IterableVal
- ✅ MinimumAge is not MinAge
- ✅ Numeric is now NumericVal
- ✅ Prnt is now Printable
🚚 Some rules were removed
- ✅ *SubdivisionCode rules: in favor of only SubdivisionCode rule
- ✅ Age: in favor of MinAge and MaxAge
- 💅 IdentityCard: in favor of PolishIdCard
- 🏗 Bank, BankAccount, and Bic: these rules were depending on the same dependency. That dependency kept on breaking the build for a while and after struggling with that so many times it seemed like removing them would be the best option.
-
v1.1.31 Changes
May 28, 2019- ⚡️ Update list of country codes
- ⚡️ Update list of currency codes
- ⚡️ Update list of language code
- ⚡️ Update list of subdivision codes
- ⚡️ Update list of top-level domains
-
v1.1.30
March 31, 2019