You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.--.
Additionally, the JS repo has the following guidelines:
A GA package should have no runtime dependencies on packages with versions 0.Y.Z or X.Y.Z-preview. Dev dependencies on such packages are discouraged but allowed.
We should add a check to our pipelines (perhaps in the "Analyze" job) to verify both guidelines. Existing violations may need to be grandfathered in, and new violations may need an exception process, but at a minimum we want to detect any new violations and have a chance to review them.
Hi @mikeharder, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.
Per semver:
Additionally, the JS repo has the following guidelines:
0.Y.Z
orX.Y.Z-preview
. Dev dependencies on such packages are discouraged but allowed.0.Y.Z
orX.Y.Z-preview
must be pinned. Even if the dependency violations Initial commit for copying files from azure-sdk-for-node #1, it should at least be pinned.We should add a check to our pipelines (perhaps in the "Analyze" job) to verify both guidelines. Existing violations may need to be grandfathered in, and new violations may need an exception process, but at a minimum we want to detect any new violations and have a chance to review them.
Depends on #24832
The text was updated successfully, but these errors were encountered: