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

PR builds aren't identifiable for backdated releases #127

Open
OmgImAlexis opened this issue Oct 18, 2021 · 1 comment
Open

PR builds aren't identifiable for backdated releases #127

OmgImAlexis opened this issue Oct 18, 2021 · 1 comment
Labels
type/feat Add a new capability or enhance an existing one

Comments

@OmgImAlexis
Copy link

Perceived Problem

So ultimately 0.0.0 is the most sensible general choice.

0.0.0 doesn't align with any of our other tools. This makes it harder to workout what the base version was that the PR is based on. A PR that's based on v1.6.0 and is going to be backdated wouldn't be the same as one based on v2.5 and is going to be merged into the main as a new version.

Ideas / Proposed Solution(s)

Allow PR builds to base their version off of the current package.json. This way PRs would be ${baseVersion}-pr.${pr_num}.${pr_release_num}.${short_sha} resulting in easily identifiable builds.

@OmgImAlexis OmgImAlexis added the type/feat Add a new capability or enhance an existing one label Oct 18, 2021
@OmgImAlexis OmgImAlexis changed the title PR builds can't identifiable for backdated releases PR builds aren't identifiable for backdated releases Oct 18, 2021
@OmgImAlexis
Copy link
Author

OmgImAlexis commented Oct 18, 2021

Users also can't update to PR builds easily as it's not seen as a step up via semver. 0.0.0 is seen as an earlier version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feat Add a new capability or enhance an existing one
Projects
None yet
Development

No branches or pull requests

1 participant