Closed AlexOlival closed 1 year ago
An addendum: this will be a breaking change, so we're talking a major version here.
Alternatively, we could deprecate the method returning the Carbon instance, and then later remove it altogether... Thoughts @JoaoFSCruz ?
Currently we are using Carbon when manipulating dates in the extractors and to define the date of birth in the Citizen model. If we just deprecate the Citizen's method to return a DateTime instance instead of a Carbon instance we are not making that of a difference.
Maybe really push for the bigger change and totally lose Carbon. 🤷♂️
Maybe really push for the bigger change and totally lose Carbon. man_shrugging
It would however mean that we could have a smoother transition to getting rid of Carbon without introducing a breaking change out of the blue. Something like v1.3.0 having a new getDateOfBirthNative()
method alongside the old Carbon
returning one, and then on v2.0, the original getDateOfBirth()
would be rewritten to return a DateTime
.
I may have misunderstood 😅
When upgrading to a later version we can get rid of Carbon. But until then we can implement another method returning a DateTime instance for a smooth transition.
That sounds totally fine 👍
As I'm working on the JS/TS/npm port, I'm striving to keep dependencies to a minimum - something that the npm ecosystem is plagued with.
However we ourselves are forcing a dependency on a
DateTime
wrapper library that, no matter how great it is, not all projects will use. PHP'sDateTime
class is fine and we should refactor our date handling to it, includingCitizen
's return type.