v5.0.0-alpha.24

[eps1lon]

Rendered changelog
Rendered release workflow instructions

Starting with this release, changelogs should be based on yarn release:changelog. For tagging, please use yarn release:tag. If you've done releases before, please check out the new instructions.

For all:

• decide on highlights
• sort contributors (would've expected appearance in changelog but that doesn't seem to be the case)
  Sorted by alphanumeric asc and moved to the end

For reviewer:

• changelog grouping
• changelog script usage
• updated release script

For me:

• generate changelog in dev CI
• resolve TODO items
• update package versions
• missing explicit dependency

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 4d48ff1

[eps1lon]

One thing we need to clarify better: How to tag.

alpha.23 was associated with a commit that is not part of this remote (af6e722).

• [ ] I'm investigating if we can rewrite this without breaking every working tree. Let's not risk it. We can guard against this in the future.

I'll probably wrap this in a script that checks if the commit is part of the correct remote.

[eps1lon]

The current behavior seems broken to me. It prompts to update every single package. Might be due to lightweight tag usage. We'll see next time if that is the case.

If lerna expects to not bump any packages I would expect an explicit option for that. Right now I can only trick it by entering the same version but that's tedious.

[oliviertassinari]

Lerna is configured to treat the version of the packages individually. @material-ui/types needed a different one.

In this mode and from what I could gather, Lerna needs one tag per managed version in order to only bump the correct packages in the next release. This was flooding the "Tags" tab view on GitHub. The current situation is the result of a tradeoff: bump everything (cons) in exchange for packages with multiple versions and a single tag (pros).

[eps1lon]

I'm not talking about tagging but updating version in the package.json. I don't understand why lerna thinks e.g. @material-ui/envinfo was changed.

I suspect it's either caused by lightweight tags or the last tag pointing to a commit that doesn't exist on the mui-org/material-ui remote. Hopefully it's not just bad DX.

[mnajdova]

One thing we need to clarify better: How to tag.

alpha.23 was associated with a commit that is not part of this remote (af6e722).

I'll probably wrap this in a script that checks if the commit is part of the correct remote.

Should we create these PRs on upstream then (mui-org)?

[eps1lon]

Should we create these PRs on upstream then (mui-org)?

This should be fixed in the new workflow. You won't run git tag on branches anymore. Just need to update the instructions to push it to mui-org/material-ui not the default remote. I don't know which commit you tagged. It doesn't seem to be the one you pushed to mui-org/material-ui

[eps1lon]

Will merge the latest state of next tomorrow after lunch (1400 CET), update the changelog, merge PR and release.

[eps1lon]

Update: Items are now numbered by their date ascending. This ensures that the numbers stay the same over time. This makes it easier to review changelog changes over time (e.g. when new items are added).

[oliviertassinari]

Update: Items are now numbered by their date ascending. This ensures that the numbers stay the same over time. This makes it easier to review changelog changes over time (e.g. when new items are added).

@eps1lon Why optimize for when each change was merged? I mean what problem does it solve for developers? I was under the assumption that all the changes are released at the same time from a developer's perspective.

So far, items have been ordered alphabetically because it makes it easier, for developers, to review changes specific to a component (grouping + predictable order). Developers don't use all the components, they might only care about a subset, e.g. Accordion.

[eps1lon]

Why optimize for when each change was merged?

Release are ordered in time so we might as well keep the order inside a release

So far, items have been ordered alphabetically because it makes it easier, for developers, to review changes specific to a component, e.g. Accordion.

They were never ordered alphabetically though.

it makes it easier, for developers, to review changes specific to a component, e.g. Accordion.

You can still do that with searching. Assuming that these are grouped is somewhat dangerous because we never explained how each components affects each other. If they assume every change affecting Accordion is grouped under [Accordion] then they ignore changes to e.g. ButtonBase. And I'm not even going into the whole "what is grouped under [Accordion]?" topic. That is currently even more confusing. Seems to me that we just removed a footgun.

Please review more thoroughly in the future. I requested the review, even pointed to the items, yet you approved. If you don't review a PR, please don't approve it. That gives a false sense of security.

[eps1lon]

And please stop doing screenshots, thanks. Either link to the text or copy it so that system defaults of text can be applied.

[oliviertassinari]

You can still do that with searching

True, it's fair. My intent was to explain why it was sorted alphabetically so far, and to get a sense of why we were changing it for developers. The first motivation shared seemed to be maintainers-focused, which could/should be secondary. While I don't understand the motivation/problem we solve, no objections to giving this a try.

Thanks for sharing the update with a dedicated component, I didn't notice the change in the first passe. I think that the image was important to contextualize the use case here, to get a feeling of the end-to-end DX (from the update developers received by email when they subscribe).

What do you mean by they were never ordered alphabetically? The usage of .sort() was meant to achieve this outcome. Do you mean that it should have used toLocaleCompare?

---

Well done with the release 🙏