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

[CT-253] Standardize Pre-release Version Format #4741

Closed
emmyoop opened this issue Feb 17, 2022 · 4 comments
Closed

[CT-253] Standardize Pre-release Version Format #4741

emmyoop opened this issue Feb 17, 2022 · 4 comments
Labels
stale Issues that have gone stale tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality

Comments

@emmyoop
Copy link
Member

emmyoop commented Feb 17, 2022

We are currently inconsistent with prerelease version format.

  • Homebrew formula versions contain hyphens. (ex: 1.0.0-rc1)

  • GitHub release tags + GHCR image tags + PyPi package versions don't contain hyphens (ex: 1.0.0rc1)

Per semver.org

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

Our CHANGELOG denotes prereleases without the hyphens currently but will start using the hypens once we move to changie (in progress)

We should move all versions to use hyphen for consistency. Current state works but consistency is better.

@github-actions github-actions bot changed the title Standardize Pre-release Version Format [CT-253] Standardize Pre-release Version Format Feb 17, 2022
@jtcohen6 jtcohen6 added the tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality label Feb 17, 2022
@leahwicz
Copy link
Contributor

@jtcohen6 if we changed the naming convention for versions to follow this convention, would there be any consequences? Cloud wouldn't have an issue but would this mess up installs from individual users at all? It would just be a change in the prerelease naming convention from what I can tell and not major/minor/patch

@jtcohen6
Copy link
Contributor

I think PyPi may not let us do this no matter what? From PEP 440:

Semantic versions containing a hyphen (pre-releases - clause 10) or a plus sign (builds - clause 11) are not compatible with this PEP and are not permitted in the public version field.

@github-actions
Copy link
Contributor

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.

@github-actions github-actions bot added the stale Issues that have gone stale label Sep 28, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Oct 6, 2022

Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest; add a comment to notify the maintainers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issues that have gone stale tech_debt Behind-the-scenes changes, with little direct impact on end-user functionality
Projects
None yet
Development

No branches or pull requests

3 participants