Semantic versioning and breaking changes

[prrrnd]

Hello,

The minor version bump from 3.1.1 to 3.2.0 introduces breaking changes. Why not making it easier for everybody and follow the semantic versioning rules that most people understand?

[JamesPlayer]

Here's another example, introducing a breaking change in a patch version upgrade: https://github.com/rails/webpacker/blob/master/CHANGELOG.md#403---2019-05-28. Is there a reason we're not following semantic versioning rules here?

[jakeNiemiec]

@JamesPlayer What if a dependency makes a breaking change? In this case, @babel/polyfill was deprecated, but not everyone uses it.

Webpacker functionality should stay the same, the only break would be if you generated a new project, but tried to use @babel/polyfill in one of your packs out of habit.

I decided to err on the "alarmist" side in the changelog since the resulting error reads like useless garbage:

Uncaught TypeError: __webpack_require__(...) is not a function
    at Module../node_modules/webpack/buildin/harmony-module.js (harmony-module.js:33)
    at __webpack_require__ (bootstrap:19)
    at Module../node_modules/@rails/ujs/lib/assets/compiled/rails-ujs.js (rails-ujs.js:822)
    at __webpack_require__ (bootstrap:19)
    at Object../app/javascript/packs/application.js (application.js:6)
    at __webpack_require__ (bootstrap:19)
    at bootstrap:83
    at bootstrap:83

[JamesPlayer]

Ah, so it was more of a PSA for people who create new projects who are used to using @babel/polyfill, the change itself was actually backwards-compatible for people just doing a version bump on an existing project?

[jakeNiemiec]

the change itself was actually backwards-compatible for people just doing a version bump on an existing project?

It depends on if you rely on @rails/webpackers implicit dependencies.

Rest assured that if the webpacker functionality or API changed in a major way (eg #2112), I'll personally lobby for semver major.