Rethink the questions beachball asks to aid devs in making better decisions
dzearing opened this issue · comments
Today, when beachball detects changes, it prompts for patch/minor/major and asks for a description. This leads to unhealthy choices for devs who can't recite the differences between them. For pre-release (v0) packages, this becomes even more confusing and beachball gives no additional information here, pushing the burden to the developer to "just know" that the package is a pre-release and that v0s have different rules about semver resolution.
One suggestion could be something like this:
Non-prerelease questions:
What kind of change are you making to the api surface of `package`?
( ) patch: No api surface changes, only changes within the api.
( ) minor: Some backwards-compatible api surface updates or additions, or visual updates which don't impact layout space.
( ) major: Changes which could cause compilation breaks for consumers or visual shift in UX. This may include removal of api surface or breaking changes to existing apis.
For pre-release packages:
What kind of change are you making to the api surface of `package`?
Note: This package is a pre-release, where semver rules are different. Read the descriptions carefully.
( ) patch: Some backwards-compatible api surface updates or additions, or visual updates which don't impact layout space.
( ) minor: Changes which could cause compilation breaks for consumers or visual shift in UX. This may include removal of api surface or breaking changes to existing apis.
( ) release: Release a major v1. Only choose this if you're confident no breaking changes will be needed in this package for a long time.