Next release v0.13.2

[oliviertassinari]

To do before the next release 🏄:

• Agree what the API name should be for the new Dialog API. Right now it's isOpen, should probably be open. react-native or the html spec are following this pattern for boolean properties ([Dialog] Use open instead of isOpen #2105) -> agreed on open, assigned to @oliviertassinari
• Make DatePicker and TimerPicker to use the new Dialog API -> needs to be updated, assigned to @oliviertassinari
• Use a small set of peerDependencies (moving some peer dependencies to dependencies #2111)
• Add import statements to docs -> assigned to @shaurya947

[vijayrawatsan]

How can I use current master as dependency? When is the next release?

[alitaheri]

@oliviertassinari inline-style-prefixer isn't a framework, it's a library, having multiple versions or instances won't break anything, it should be dependency so that we won't have to add it to our package.json 😁.

👍 for open

[mgibeau]

May I suggest you postpone theses changes for a future release, there are currently a lot of fixes in master that could be released separately without introducing breaking changes.

[oliviertassinari]

@mgibeau We have merged a lot of PRs since the last release. Since we have very few unit test, I think that I would be safer to make the next release a minor update instead of a patch update.
@shaurya947 What do you think?

[shaurya947]

I agree with @subjectix: move inline-style-prefixer to dependencies, and use open prop for Dialog.

@oliviertassinari are you suggesting a v0.14.0? Hmm... I would ideally like to do one more patch release before that. But if you really feel that way, then I'm fine with a minor release. Also, are you (or someone else) working on updating TimePicker and DatePicker to use the new Dialog API?

[oliviertassinari]

@shaurya947 What we could do, is release a v0.13.2 with all the commits before the change of API for the Dialog and release a v0.14.0 with the change of API of the Dialog.
Or release a v0.13.2 with a fix for the server side rendering and a v0.14.0 with the rest.

[alitaheri]

@oliviertassinari The changes aren't really breaking anything. they just deprecate. maybe it's not bad to have a patch informing people so we can remove the extra code with a minor imo.

[shaurya947]

@oliviertassinari I like @subjectix's idea. If we don't have any breaking changes (which it seems we don't) let's just release a v0.13.2 now (with any deprecations and their warnings). Then when we release v0.14.0 in a week or so, we can completely remove the deprecated code.

[oliviertassinari]

@shaurya947 I'm ok with this 👍. Let's fix the Dialog API and the dependencies and then release v0.13.2 💃.

[shaurya947]

@oliviertassinari also the import statements, that I'm working on right now.

[mgibeau]

@shaurya947 I don't agree with this, I don't see why you would hold up a release for API changes, especially considering the state of the current release not working at all (edit: when using server rendering).

[shaurya947]

@mgibeau v0.13.2 will have all the PR fixes since the last release (including the fix for the server rendering). How is that holding up anything?

[mgibeau]

@shaurya947 Sorry, by holding up I meant adding more scope. The Dialog API doesn't need to change before releasing what's currently in master.

[shaurya947]

@mgibeau the dialog API is not being changed per se. Only the prop name is being changed from isOpen to open because many users feel that open is a more appropriate name. We have deprecated some of the old prop names. Other than that, master shall be released as is.

[shaurya947]

Done. Great job guys 👏