-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release following semantic versioning #13160
Comments
What was the breaking change in 3.2.0? I agree with everything else. A v4 branch and beta release would be a good idea. |
My mistake, re-read through the release notes and see I misunderstood them. Looks like |
@zachwolf That was my mistake. The change was done for the wrong reasons. Out of it, we came up with #12752. Hopefully, we will do a better job at it going forward. The v3.2.0 and v4.0.0 (~4 months from now) release should be an example of this effort. Any more concern? |
Awesome, thanks for the quick responses and sorry for the noise. Looking forward to 4.0 🥇! |
I've noticed recently that moving from 4.8.0 to 4.8.3 brought in some breaking changes. They were minor enough (breaking change to It's saddening when you can't be sure if you can trust patch-level releases. I don't want to trigger anyone's Hauptversionsnummernerhöhungsangst but it would be nice to at least get clearer documentation about breaks, even when the releases don't follow semver. |
@vdh What was the breaking change in Typography? |
@eps1lon It was The Thankfully the documentation did get some updates to show how to migrate, but it would be better if the breaking changes and how to migrate them were easier to track down. I don't fault the lab components for breaking due to being in alpha, but something like |
Hey y'all!
Thanks so much for all your work on mui. We use it every day and it's invaluable.
Expected Behavior
Releases would follow the the semver guide, per the docs:
Current Behavior
At least 2 releases now have not followed this pattern.
Examples
3.2.0 introduces a breaking change but does not increase major version.My mistake, this change is backwards compatible.Context
I can definitely empathize with not wanting to release major versions constantly. However, it makes it extremely difficult to not be able to able to rely on semver when updating many packages. As a global npm issue, It's significantly more time consuming to go through each repo's change log to check if they're following proper semver, rather than being able to update to everything that's not a major release.
Per the above screenshot, it looks like v4 is coming in the next few months. Perhaps break a v4 branch that can release beta versions. If adopters want the latest and greatest and are willing to accept breaking changes they can pull from these releases. However, for developers that need a predictable release schedule, they'd be able to pull from 3.x.x safely.
Thanks, looking forward to hearing your thoughts!
The text was updated successfully, but these errors were encountered: