Let's ship v1!

Well, not yet. We need a plan for doing so. The v1 effort started 18 months ago. We have had some interesting discussion in #9388 and #9614. Here are the problems I want to solve all at once:

1. How can we make the migration from v0.x to v1 as smooth as possible? Right now, people have to do it in a single batch. It’s very hard.
2. How can we scale the number of components we support? The community has been building a lot of components on top of Material-UI, with large quality distribution.
3. Some of our components are pretty stable while some aren’t. Should the few unstable components prevent us from releasing the stable components earlier?

I’m proposing the following plan, any feedback is welcomed. If we follow it. I’m expecting the to see the first v1 stable release of our components in a month or two and to complete it in 6 months or so.

We take advantage of @material-ui npm scope name

Effectively people imports will change:

-import { Button } from 'material-ui';
+import { Button } from '@material-ui/core';

I have opened a poll on Twitter to collect some feedback.

Pros

• It will signal to the world what’s official and what’s not.
• It will prevent any future package name clashing.
• It will make the transition from v0.x to v1 much easier. Without, it’s really tricky as some external libs might be relying on material-ui@0.x while others on material-ui@1.x. In this situation, people can’t have both versions installed at the same time. They only have one option. They do the migration in one go. This solves pain point n°1 and a bit of n°2.
• We can remove 2k lines of code and close #9469.

Cons

• The downloads stats restart from scratch. It should only be a short time issue. It’s not something I would worry about.

Overall, the Babel blog on this topic is very interesting https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release.

We create a lab package

The package can be named @material-ui/lab or @material-ui/denovo as @rosskevin likes it. What’s more important is that we can leverage this package.

Pros

• Right now we can consider all our components as belonging to the lab. But as we solve all the core issues and stabilize some components, we can start promoting and gradually components from lab to core (stable). It’s solving problem n°3. v1 will be complete once we merge v1-beta into the master branch and we move https://material-ui-next.com to http://material-ui.com.
• Let’s say we ship X, a new component as soon as we merge the pull-request. People might jump to conclusion. “X is buggy, I bet the other components are the same. I’m not going to use this crap”. Having a lab package is creating a clear contract. People know what they can expect from the components. It’s solving problem n°2.
• Releasing a high-quality component is a time-consuming process. People feedbacks are critical. Having a lab package can encourage people giving feedback.
• We can do more experimentations.

Cons

• We will need to set up the infrastructure needed for such package.

Overall, the Blueprint approach in interesting to have a look at http://blueprintjs.com/docs/#labs.

mono-repository ❤️

No matter what. I think that we should try very hard to keep the project in a single GitHub repository.

cc @mui-org/core-contributors

[oliviertassinari]

What if material-ui has a breaking change and multiple lab components need to be updated?

@leMaik I’m glad you are asking. It’s where a large chunk of the mono-repository value comes (https://github.com/mui-org/material-ui/pull/9614#issuecomment-354568219). You save a lot of synchronization effort. You can migrate everything in one go. However, as the code base grows, it’s taking more time. It’s the same tradeoff behind monoliths vs micro-services architecture: inertia (weight) vs synchronization hell.

However, your point is valid, we need to address the following problems:

• The Material Design specification is very large. It’s much more work than one person can handle full-time. We need to efficiently split the effort among different people. It’s a non-goal for me to cover all the subtleties. I have no incentive for doing so. However, some people need to address edge cases and will write code to do so. How do we make this effort efficient?

So, I believe we need a third entity:

1. core: core stable components that 80% of the people will need: mono-repository (material-ui).
2. lab: core components we wish will be stable enough one day to move into the core: mono-repository (material-ui). It’s allowing us to do experimentations.
3. complementary components for the long tail: independent repositories (material-ui-X). They will have their own lifecycles. The maintainers can watch the project without being flooded with noise. It’s creating ownership. It’s what people have been naturally doing so far. The difference now if that we have our own GitHub organization. We can host some of those complementary components under mui-org. We can make them more official, increase exposure. Those components can be published on npm under the @mui-org scope.

[eyn]

@oliviertassinari - I like the lab/core idea. There’s a pretty strong argument in my view to release v1 asap.

Right now people are starting projects with v0.x which given the quality and stability of v1 they shouldn’t be. They are just creating extra work for themselves as they will have to transition at some point. There are lots of us using v1 in production already with no problems and the odd breaking change is less hastle than upgrading from v0 to v1. And the labs/core designation might make this easier. Ie a core breaking change requires a semantic version change with a release train that departs once a month and a labs release train departs once a week. One downside of this might be dependencies between a core change and a labs component requiring that change. Is there a good pattern on how to handle that?