Material-ui: jss-theme-reactor version should't use charet

[giuseppeg]

Problem description

In package.json you have jss-theme-reactor@^0.9.0 which won't install 0.10 and above.

At work I am using 0.10 and I need MaterialUI to use the same.
Maybe you can change the version to 0.x ?

Versions

• Material-UI: next

[giuseppeg]

To clarify

Caret Ranges allow changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple.

In our case the left-most non-zero digit is 9 (0.9.0) therefore ^0.9.0 resolves to >=0.9.0 <0.10.0. You can try this on semver.npmjs.com.

Read more about this on the npm website.

[kof]

We kinda stuck because of that, because we can't override the jss-theme-reactor version locally. Mui is still installing a local 0.9.0 version even if we put 0.10.0 in our dependencies.

[kybarg]

Latest release v1.0.0-alpha.6 depends on jss-theme-reactor@^0.10.0

[kof]

Ah awesome! Haven't seen yet. We should still use 0.x instead of ^ until we release jss-theme-reactor 1.0, then we can go back

[mbrookes]

@kof For 0.x releases, minor releases can include breaking changes. That is why the caret range works as it does https://github.com/callemall/material-ui/issues/6227#issuecomment-282702313.

If we removed the caret, we would run the risk that breaking changes in jss-theme-reactor could break Material-UI. It is correct as it is.

[giuseppeg]

@mbrookes maybe jss-theme-reactor should use proper semver then? I mean versions are free I don't get why people use minor for major -.-

[kof]

I guess jss-theme-reactor wasn't stable enough to release 1.

[kof]

For 0.x releases, minor releases can include breaking changes

Why should breaking changes be released with minor version?

[giuseppeg]

you can always release 1.0.0-unstable and 0.10.0[-stable]

[giuseppeg]

Why should breaking changes be released with minor version?

@kof that's the whole point, people "misuse" semver – I get why but it is not necessary.

[mbrookes]

@kof @giuseppeg That isn't a misuse, it's using semver as intended. For pre-1.0 breaking changes are allowed in minor releases.

The big question is - when should you release 1.0? React jumped from 0.14 to 15.0 because they realized that React had long since met the criteria for a 1.0 release. Arguably master here should be 1.x already, and next would be 2.0, but it didn't feel right to release a 1.0 version just as we were embarking on a complete rewrite - declaring the cake baked and inviting everyone to tuck in, when we have a chocolate souffle in the other oven, so to speak. :smile:

[giuseppeg]

breaking changes are allowed in minor releases

Correct but it doesn't mean that you have to treat minor as major and pin dependencies in the library. Developers know that the API should not be considered stable and therefore pin the dependency in their own project. fwiw then Semver doesn't define the concept of caret ranges.

The big question is - when should you release 1.0?

http://semver.org/#faq

That said, I like _the cake_ and thank you for the fast upgrade/release cycles ✌️ :)

[mbrookes]

http://semver.org/#faq

Yup, I was going to link to that. At the point in time I'm referring to, we didn't consider the API stable. We we're discussing changing quite a few aspects of it on master. Then next happened, and, well, here we are. The focus is now on next, and master is is sort of in maintenance mode.

Should jss-theme-reactor be 1.x? That's a question for @nathanmarks :smile:

Developers know that the API should not be considered stable and therefore pin the dependency in their own project.

We can't assume that developers are using jss-theme-reactor (or other Material-UI dependencies) in their own project, so we have to pin those at compatible versions in the library itself.

And there we have come full circle: https://github.com/callemall/material-ui/issues/6227#issuecomment-283166953 Can we close this now?

[giuseppeg]

@mbrookes yeah, I mean the issue is not solved but I can live with that :)