[CHANGELOG] Prepare v5.0.0-alpha.23

[mnajdova]

• I have followed (at least) the PR section of the contributing guide.

[mui-pr-bot]

No bundle size changes

Generated by 🚫 dangerJS against 76a5b35

[oliviertassinari]

This has a narrower impact, and is not about the lab package per say

Suggested change

	- [lab] Prevent possible null pointer in useValidation (#24318) @eps1lon
	- [DatePicker] Prevent possible null pointer in useValidation (#24318) @eps1lon

[eps1lon]

These are still not only targetting the DatePicker.

[oliviertassinari]

"DatePicker" has been used, so far, as a placeholder for all the date picker components (when something more specific doesn't exist).

We could make them inside of [core] in this case, if you consider it's internal.

[lab] is about change that are specific to the lab package, like fixing the TypeScript issue because we have a lab package and we don't have the components in the core package

[core] is about all the devops work and code infrastructure that supports the public modules.

[eps1lon]

It's not devops. It's about components in the lab.

[oliviertassinari]

Ok so it's about the date pickers, at large? This mention in the changelog would create a precedent. I think that we should optimize for what the developers reading the changelog would want to know. From my perspective, it seems more relevant to know that it's linked to a better date picker (and all its variants). I assume that the npm packages core/unstyled/styled/etc. are only means to bundle and distribute the different modules.

[eps1lon]

Ok so it's about the date pickers, at large?

Date and time pickers. Not just date pickers.

I think that we should optimize for what the developers reading the changelog would want to know.

We agree on that

it seems more relevant to know that it's linked to a better date picker (and all its variants).

A time picker is not a date picker.

[oliviertassinari]

A time picker is not a date picker.

I guess our disagreement comes from this, I was considering it to be close enough.

• Semantically and conceptually close

• JavaScript new Date().
• Time picker is not was most developers are looking for. I think that we will more accurate state once v5 is released as stable and we can look at GA page views, but early data I could get my hand on would suggest the TimePicker is about 25% of the need compared to the DatePicker.

[mnajdova]

Should we then leave this as lab at this moment and merge? I'll start with the release right away

[oliviertassinari]

Maybe we could create a new label that includes DatePicker, TimePicker, DateRangePicker, DateTimePicker. Historically, we have used Pickers but it's a bit confusing without more context.