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

Rethink the questions beachball asks to aid devs in making better decisions #954

Open
dzearing opened this issue Mar 13, 2024 · 0 comments

Comments

@dzearing
Copy link
Member

dzearing commented Mar 13, 2024

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant