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

Pre-release version support #11

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from
Draft

Pre-release version support #11

wants to merge 11 commits into from

Conversation

mroth
Copy link
Owner

@mroth mroth commented Jan 20, 2020

In the background I've been chipping away at what support for "pre-release versions" would look like in bump.

In short, the non-edge case version of this would be something like:

  • If the previous release was a pre-release, detect it and suggest the next incremented pre-release or the "finalized" version as the two possible next versions. (e.g. 1.2.3-rc.2 should suggest 1.2.3-rc.3 and 1.2.3 as the next two possibilities). Since there is no required format for prerelease field contents in semver, need to detect, parse, and increment all of the most common format possibilities (e.g. -rc.1, -rc1, -1, etc etc etc.) while preserving the user's original schematic.
  • Have some way to create an "initial prerelease" (e.g. ability to select prepatch, preminor, and premajor) if the previous release was a normal one. We can probably just use a (configurable) default here, e.g. rc.1 or some such. Whether these less common options are always visible (what np does, easy but kinda ugly/confusing to always have it there), or are special cased with --pre CLI flag or something, is an open UX question.

Some bulleted requirements:

  • Library/API for handling pre-release parsing/incrementing, suggesting next versions, etc. (In progress, mostly functional).
  • Handle integration issues with GitHub releases.
    • GH API getLatest on releases ignores prerelease flagged releases! Need to iterate entire list ourselves and build out own results.
    • Rationalization/conversion between standard semver prereleases and GitHub prereleases (GH does their own thing here as well)
    • Preset GH pre-release flag properly when drafting a new release.
  • Figure out CLI UX challenges (kinda tricky to preserve simplicity)
  • Documentation updates

@mroth
Copy link
Owner Author

mroth commented Jan 20, 2020

UX Thoughts

One UX option would be to have the initialPreleases "always visible" in the typical case but hide it below the field, so less visually distracting.

Example with all options present, this is how np does it:
Screen Shot 2020-01-20 at 4 14 30 PM

Example below the fold with scrolling. In this option, the "initial view" would be the same as it was previously, albeit with the down arrow disclosure hint. (In the example screenshot here, I already scrolled down one below the fold):
Screen Shot 2020-01-20 at 4 15 18 PM

The case where we are on an existing pre-release is pretty cut and dry, I think it's certain we want to just display the two reasonable suggestions:
Screen Shot 2020-01-20 at 4 27 28 PM

Lots of attempting to deal with the discrepancies between how GitHub
releases work in practice, and what semantic versioning says about
pre-releases.

As part of this, we need to query enough data to know multiple releases,
since a) the GitHub API does not return releases flagged as prerelease
in its UI as part of getLatest, b) if we are on a prerelease version,
we need to also be able to know the last FULL release to generate a more
helpful changelog.
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

Successfully merging this pull request may close these issues.

None yet

1 participant