Skip to content
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

Closed
2 tasks done
zachwolf opened this issue Oct 8, 2018 · 8 comments
Closed
2 tasks done

Release following semantic versioning #13160

zachwolf opened this issue Oct 8, 2018 · 8 comments

Comments

@zachwolf
Copy link
Contributor

zachwolf commented Oct 8, 2018

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:

Given a version number MAJOR.MINOR.PATCH, increment the:

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

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Current Behavior

At least 2 releases now have not followed this pattern.

Examples

  • 3.0.0 was released just to mirror the icons and completely skipped 2.0.
  • 3.2.0 introduces a breaking change but does not increase major version. My mistake, this change is backwards compatible.

screen shot 2018-08-28 at 10 14 31 am

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!

@eps1lon
Copy link
Member

eps1lon commented Oct 8, 2018

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.

@zachwolf
Copy link
Contributor Author

zachwolf commented Oct 8, 2018

My mistake, re-read through the release notes and see I misunderstood them. Looks like <Button variant="flat" /> will still work in 3.2.0 but just give warnings. I've edited my original post to correct this.

@oliviertassinari
Copy link
Member

oliviertassinari commented Oct 8, 2018

3.0.0 was released just to mirror the icons and completely skipped 2.0.

@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?

@zachwolf
Copy link
Contributor Author

zachwolf commented Oct 8, 2018

Awesome, thanks for the quick responses and sorry for the noise.

Looking forward to 4.0 🥇!

@zachwolf zachwolf closed this as completed Oct 8, 2018
@vdh
Copy link
Contributor

vdh commented Jan 21, 2020

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 TypographyProps in Typescript, Skeleton disableAnimate prop replaced with animation={false}), but it was frustrating that the release notes said very little about these breaks and I had to go hunt for the information about them and how to migrate. I spent more time debugging and hunting for info than I did actually migrating.

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.

@eps1lon
Copy link
Member

eps1lon commented Jan 22, 2020

@vdh What was the breaking change in Typography? Skeleton part of the lab which is published as an alpha version. Any new alpha version is allowed to introduce breaking changes.

@vdh
Copy link
Contributor

vdh commented Jan 28, 2020

@eps1lon It was The TypographyProps changes: #18868 (comment)

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 breaking or breaking change in or next to a change in the release notes would at least make it obvious where I need to start looking for migrations to make.

@oliviertassinari
Copy link
Member

@vdh Updated: https://github.com/mui-org/material-ui/releases/tag/v4.8.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants