v5.9.0

[flaviendelangle]

• Compare the last tag with the branch upon which you want to release (next for the alpha / beta releases and master for the current stable version).
  To do so, use yarn release:changelog The options are the following:

  yarn release:changelog
     --githubToken   YOUR_GITHUB_TOKEN (needs "public_repo" permission)
     --lastRelease   The release to compare against (default: the last one)
     --release       The branch to release (default: master)

  You can also provide the github token by setting process.env.GITHUB_TOKEN variable.

  In case of a problem, another method to generate the changelog is available at the end of this page.

• Clean the generated changelog, to match the format of https://github.com/mui/mui-x/releases.

• Update the root package.json's version

• Update the versions of the other package.json files and of the dependencies with yarn release:version.

• Fix manually the package version in x-date-picker/package.json and x-date-picker-pro/package.json.

• Open PR with changes and wait for review and green CI.

• Merge PR once CI is green, and it has been approved.

Release the packages

• Checkout the last version of the working branch
• Make sure you have the latest dependencies installed: yarn.
• Build the packages: yarn release:build.
• Release the versions on npm: yarn release:publish (you need your 2FA device).
• Create a new tag named with the release you just did git tag -a v4.0.0-alpha.30 -m "Version 4.0.0-alpha.30" && git push upstream --tag

Publish the documentation

The documentation must be updated on the docs-vX branch (docs-v4 for v4.X releases, docs-v5 for v5.X releases, ...)

• Push the working branch on the documentation release branch to deploy the documentation with the latest changes.

git push upstream master:docs-v5 -f

You can follow the deployment process on the Netlify Dashboard
Once deployed, it will be accessible at https://material-ui-x.netlify.app/ for the docs-v5 deployment.

Publish GitHub release

• After documentation is deployed, publish a new release on GitHub releases page

Announce

• Follow the instructions in https://mui-org.notion.site/Releases-7490ef9581b4447ebdbf86b13164272d.

[flaviendelangle]

It is currently not very clear which packages are impacted by these core changes.
Sometime it is a change cross package (for the doc gen for instance)
But sometimes it is a change inside one of the package.

Should we prefix by the component family here instead of "Core" now that we have several ?
For instance

• [infra] Don't upgrade CircleCI node ([core] Don't upgrade CircleCI node #4457) @m4theushw
• [infra] Fix flaky e2e-website tests in CI ([test] Fix flaky e2e-website tests in CI #4136) @cherniavskii
• ....
• [pickers] Fix typos and JSDoc ([core] Fix typos and JSDoc #4406) @flaviendelangle
• [data grid] Move away for the event system to trigger pipe processings ([core] Move away for the event system to trigger pipe processings #4378) @flaviendelangle

[cherniavskii]

Can we keep [core] prefix and use label to differentiate between data grid and pickers?

[alexfauquette]

I do not see a big interest in replacing [core] because developers do not really need to read those lines.

[flaviendelangle]

It is mostly for us, as the team grow I think it should be clear looking at a PR if it impacts the pickers or the datagrid, or the charts, etc...

But the label could work.
That would mean put the "data grid" label on the "[core]" PR that modifies code on the grid packages (same for pickers).

[cherniavskii]

That would mean put the "data grid" label on the "[core]" PR that modifies code on the grid packages (same for pickers).

Makes total sense to me.

[m4theushw]

The core repo seems to use [core] only for changes in the infra. I think we used [core] in the past because there was a lot of changes in internal parts. Maybe now, with two components, makes sense to use the prefix of the component affected. The "Add technical doc for pipe processing and family processing" item I would keep with [core] because I understand that [docs] is only for changes that affect the deployed docs.

[flaviendelangle]

I understand that [docs] is only for changes that affect the deployed docs.

Agree

---

As for moving everything not infra inside the package sections, I don't have a strong preference

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	270.6	582.4	503.7	444.18	139.238
Sort 100k rows	ms	513.9	1,273.7	731	858.44	252.951
Select 100k rows	ms	122.9	300.8	178.3	202.4	74.79
Deselect 100k rows	ms	108.7	221.3	178.9	169.64	47.456

Generated by 🚫 dangerJS against 8e7848a

[alexfauquette]

I do not see a big interest in replacing [core] because developers do not really need to read those lines.