Rmwc: RMWC is not bumping the semver major version when introducing breaking changes.

[vasco3]

RMWC or MDC?

RMWC

What RMWC Version are you using?

v1.9.2

What is the expected behavior?

RMWC should bump the major version when there are breaking changes.
For example changing the use prop to icon prop in Icon component. That is a breaking change that will break an app.

What is the actual behavior?

RMWC introduces breaking changes without bumping the major version.

Any other information you believe would be useful?

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.

reference: https://semver.org

[jamesmfriedman]

Without getting into a full blown argument about the merits or issues with Semver, I am well aware of limitations of the current release scheme. A few things:

• For the record, Icon isn't a breaking change, it's a deprecation. The old method will still work but will throw a warning. I realized this would have a massive impact on lots of components so this is the first official deprecation I've put into the library.
• material-components-web revs breaking changes as minor releases. As I've learned from falling into this trap, specific versions are best when installing dependencies since we basically only have the honor system for what someone publishes to npm and what someone considers breaking.
• NPM defaults to install ^x.x.x which as you probably know will auto update the minor and patch. Guidance on this would be to change it to ~x.x.x for RMWC which will only auto update the patch version which I can promise won't have breaking changes.
• In true google fashion, the material-components-web team is still calling their library "alpha" which is silly for a library thats got 10K stars and has been around for a year and a half. I've done my best to withhold my opinions about the fact that they like to break things, which is about every release.
• I'm saving V2 for react-fire which will be the king of breaking changes if they go through with it. At this point, I'll have to maintain two codebases for a while
• Lastly, I'm going to put in the work to break up the mono repo into individual packages while still allowing it to be installed and used as a mono repo. This should allow people to upgrade components individually and use the latest version of the drawer with the oldest button. It's going to be challenging, but hopefully worth it. Would love help if you have any knowledge on the subject.

[vasco3]

About the point #1, sorry for the sloppy example. A better example would be the deprecation on DrawerHeaderContent. Kudos for the deprecation notice on icon. I consider that very pro (react-like).

I understand that as long as mdc has the major version 0 they are in alpha so they can introduce breaking changes until they reach v1.

I do lock my npm packages but it's hard to follow the rmwc docs while using an older version so that's why I opted to upgrade.

React had the same semver issue until they realized it and they upgraded from 0.14 to v15.
The same story with NodeJS from 0.1x to v4. npm the same.

Just wanted to point it out, but it's fine if it stays like this.

Thanks for taking the time to look review the issue.

[jamesmfriedman]

Oh, no @vasco3, my points aside I’m definitely changing this to honor semver with the mono repo split. Expect a V2 followed by a V3 V4 V5 in the near future.

[vasco3]

Awesome @jamesmfriedman

About the mono repo I know babel uses lerna. I haven't tried it myself. Looks like it alleviates the pain of publishing npm packages individually.

Looks like rmwc is a good candidate for having a Patreon, or Open Collective or something similar so people can chip in.

[jamesmfriedman]

@vasco3 thanks for the tip.

Is the one that suggests the first to donate? https://opencollective.com/rmwc/ 😜

[vasco3]

done!

[jamesmfriedman]

haha, thanks @vasco3!