Soft dependencies version breaks existing software on each new MJML release

MJML use caret range version to pin internal dependencies.

^4.1.2 is equals to ≥4.1.2 <5.0.0, so on each new minor release of MJML, existing software using previous release are forced to upgrade all inner mjml-* dependencies.

$ cat package.json 
{
	"dependencies": {
		"mjml": "4.1.2"
	}
}
$ yarn
success Saved lockfile.
$ ./node_modules/.bin/mjml --version
mjml-core: 4.2.1
mjml-cli: 4.2.1

It breaks at least softwares expecting specific MJML version, like mjml-rails and generate unreproductible builds (using MJML 4.1.2 before the 4.1.3 release is not the same as using it after).

It would be better to pin internal dependencies to the exact same version as the main MJML package, or to use at least tilde range version to avoid minor version change.

[iRyusa]

I don’t really see tilde as an issue IMO, as minor patch only provide fix introduced in the branch, I’ve fucked up merging a PR that was aimed for 4.3.0 and released it among a minor patch ( note that it only affect people that still use MJML3 syntax over MJML 4, after a year )

Tilde was an accepted solution in MJML3, and we didn’t have any complaints about it for a while. As we moved on lerna, to ease package management, we didn’t saw that mistake and it’s good that someone found it, so we can either go on tilde again, or pinning the version.

this as a viable solution for production anymore because of this unpredictability.

Lock files is a viable solution to pin package version also, you can also just enumerate the different package for MJML in your package.json like here https://github.com/mjmlio/mjml/blob/master/packages/mjml/package.json

After this biting us twice with the past 2 releases - 4.2.0 and 4.2.1, and killing developer time to just try to figure out why suddenly email isn’t rendering

I feel like we try to reply on Github & Slack & fix ASAP issues introduced in any minor or major patch.

But I think that brings up another question of why are patch releases introducing breaking changes?

It’s open source and free, we do some mistakes, we’re not perfect. So, feel free to take some of your free time, like us, to reply to some MJML users & fix bugs in it too 😃

On Sat, Dec 1, 2018 at 2:32 AM Phillip Novess [e-mail] wrote:

~ & ^ both seem like unacceptable solutions. @aeris https://github.com/aeris solution seems like the best, pin the internal version dependancies to exact versions. Currently the way this project is organized, I don’t see how you can install the version you actually want. I put “4.2.0” in my package.json file, I expect to have that installed.

After this biting us twice with the past 2 releases - 4.2.0 and 4.2.1, and killing developer time to just try to figure out why suddenly email isn’t rendering, and trying to enforce a stable version, we are on the cusp of dumping this as a viable solution for production anymore because of this unpredictability. And that is with just with the past 2 patch releases. But I think that brings up another question of why are patch releases introducing breaking changes?

Please offer any suggestions. We would love to use this is awesome project. Unfortunately, we don’t have the luxury of every deploy possibly breaking cause we can’t control the package version.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mjmlio/mjml/issues/1442#issuecomment-443387689, or mute the thread https://github.com/notifications/unsubscribe-auth/AAizzefdaADCjNfy0pZ5hhAAZRGkYR7Tks5u0dxDgaJpZM4Y4DPX .

[bluengreen]

~ & ^ both seem like unacceptable solutions. @aeris solution seems like the best, pin the internal version dependancies to exact versions. Currently the way this project is organized, I don’t see how you can install the version you actually want. I put "4.2.0" in my package.json file, I expect to have that installed.

After this biting us twice with the past 2 releases - 4.2.0 and 4.2.1, and killing developer time to just try to figure out why suddenly email isn’t rendering, and trying to enforce a stable version, we are on the cusp of dumping this as a viable solution for production anymore because of this unpredictability. And that was with patch releases. But I think that brings up another question, why are patch releases introducing breaking changes?

Please offer any suggestions. We would love to use this awesome project. Unfortunately, we don’t have the luxury of every deploy possibly breaking cause we can’t control the package version.

https://github.com/sighmon/mjml-rails/issues/39#issuecomment-429509358