Skip to content

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

Open
@dzearing

Description

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.

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions