Merging master in release

[dtassone]

No description provided.

[dtassone]

Merging master in release. I will publish and deploy once merged

[oliviertassinari]

Have you considered to release from master directly? Have you considered to push force master to the release branch?

[dtassone]

Have you considered to release from master directly? Have you considered to push force master to the release branch?

I don't want to release from master as we can break things easily on this branch. And that way we can control a bit more when we release.
I can do force push but I thought it was nice to use a PR and track when we release...
It's our branching model
[Feature]=> [Master] => [Release] (tag and publish package from this branch) => [master] (we merge release back to master to get the version update)

[oliviertassinari]

I don't know what's the best approach around handling release, some of the things I think are important:

• We know for each pull request/commit, in which version it was released
• We generate a human-friendly and detailed changelog people can read
• As much as possible is automated, to remove room for mistake & stress
• We leverage https://github.com/mui-org/material-ui-x/releases

A few tools we could leverage:

• https://github.com/conventional-changelog/conventional-changelog
• https://github.com/conventional-changelog/standard-version

I know that @eps1lon started to work on release automation, but I think that it was put on hold.

I recall we had a debate around either we should have one tag/commit per package release or a single tag that bundles all the released packages.

[eps1lon]

I know that @eps1lon started to work on release automation, but I think that it was put on hold.

Because I don't want to have discussions about the version every time. I would be nice if we could recognize SemVer but we only mention it in name. And every time we actual do a release we have to go over what we personally consider "minor" or "major" or if it's "likely to break".

I repeat what I said before: Do what works best for you on this repository. There isn't a single right way to do things that should be repeated just in pursuit of "consistency".

[dtassone]

I repeat what I said before: Do what works best for you on this repository. There isn't a single right way to do things that should be repeated just in pursuit of "consistency".

I definitely agree with this sentence :)

And I also believe that we need to improve our release process for X. The process is currently manual, but bear with us, we are still in early-stage with the project.

[oliviertassinari]

I don't want to have discussions about the version every time.

@eps1lon From what I understand, we could simplify the discussion by using https://www.conventionalcommits.org/. It would then come down to what's the correct commit message for each pull request.

Do what works best for you on this repository. There isn't a single right way to do things that should be repeated just in pursuit of "consistency".

I think that the pursuit of "consistency" is fruitless. It can only be the consequence of an objective or a tool to reach an objective. It should never the objective itself. For instance, consistency of the pattern of children?: React.Node forces us to question which approach is the best one and also remove doubts about which approach to pick.

I share some of what I think the strategy should be in #115 (comment) (the what and why). The key elements for treating the two repositories as a single entity:

1. It forces the confrontation of conflicting points of view. I think that the best way to find the best approach is by resolving the opposite views people have on topics. There is something to learn. The sooner, the better.
2. It forces us to hit reality. By deploying solutions that cover the whole scope of the problems we are facing, I think that we are making better decisions.
3. It scales better. While having 1 person working on material-ui-x and 1 person working on material-ui allows us to bypass 1., this doesn't prepare ourselves to have 5 persons on each. At which people, contribute will frequently contribute to the two repositories. Treating the codebase as identical will then become an obvious necessity.
4. DevOps is hard. We have experienced it first hand from the main repository, building the infrastructure to support the authoring of leading UI components is hard, we often have to build the tools for ourselves as nothing is available in the community (or of poor quality). We have a significant opportunity by not duplicating this effort.

---

I also think that once we get more than 10 people in the team, it starts to make sense to allow more explorations and short/medium-term divergences, as the potential ROI increases.