Usage of the `date-io` adapters on MUI packages

[flaviendelangle]

I am starting this discussion, because we are starting a major rework of our date and time pickers, which will require to modify the adapters significantly.

Therefore, we would like to discuss with you beforehand to see how you feel about @date-io and how we can organize together to improve this project with as little friction as possible.

Here are a few examples of evolution we will need:

1. Add a new method splitting a date format into an object describing each section of the format
2. Add new utility methods like startOfHour / endOfHour / ...
3. Update to Luxon 3 to take advantage of the new DateTime.expandFormat utility method.

This raises two major questions:

• Is it okay to make such major evolution (including potential breaking changes) to your packages "just" for our components or should we fork to avoid impacting the other users of @date-io
• How can we avoid to bother you each time we need a small release to add an utility method like startOfHour and to avoid friction if your are on vacation for instance

Best regards,

Flavien

[dmtrKovalenko]

Hey, great questions.

1. Adding new methods are great until they do not require additional plug-ins (this is weird for end user)

2. Same

3. Updating Luxon is also ok but will require breaking change. Make sure that breaking changes of date-io doesn't mean to be breaking change for end-user, only for library authors.

[dmtrKovalenko]

Related to releases -- The repository is under my namespace and I added you as a collaborator.

We can try to add a semantic release bot adnd release on each merge to release branch. But you need to make sure that CI is green

[flaviendelangle]

Concerning the new methods, I started by adding them on our repo to stabilize them before adding them here.
You have an example for date-fns here.

For the Luxon update.
It will also bring support for getFormatHelperText.

Make sure that breaking changes of date-io doesn't mean to be breaking change for end-user, only for library authors.

Not sure to understand that one.
If we update to Luxon 3, people will have to upgrade there app to Luxon 3 as well if they want to keep updating there @date-io/luxon package.
We are you refering to when you say "breaking change for end-user" ?

We can try to add a semantic release bot adnd release on each merge to release branch. But you need to make sure that CI is green

I'm not going to merge anything without a green CI of course.

[dmtrKovalenko]

I mean that the end user of date-io is library and breaking change for library authors is not as hard as breaking change for end-users, but I would be much more happy if we can upgrade without any breaking changes if possible.

We didn't have braking changes for couple years and we need to remove already not working functionality for inferring types through npm modules. So feel free to update luxon right now.

[flaviendelangle]

So feel free to update luxon right now.

I guess that would be a major of the @date-io/luxon package (and probably the other for ease of use).
If we can do a major in the coming months, of course I can spend time doing the other improvements you have in mind.

How do you want to do it ?

[dmtrKovalenko]

I have a pr #416 which is a breaking change in terms of the whole package

[oliviertassinari]

Since MUI doesn't have a dependency on @date-io anymore (https://github.com/mui/mui-x/releases/tag/v6.3.0), maybe this issue should be closed?