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

[SR-15372] DocC should allow versions of the legal "pre release" sem-ver formats (e.g. 1.2.3-SNAPSHOT) #214

Closed
ktoso opened this issue Oct 22, 2021 · 5 comments
Assignees
Labels
enhancement Improvements or enhancements to existing functionality

Comments

@ktoso
Copy link
Member

ktoso commented Oct 22, 2021

Previous ID SR-15372
Radar rdar://84540229
Original Reporter @ktoso
Type Improvement
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Swift-DocC
Labels Improvement
Assignee @d-ronnqvist
Priority Medium

md5: a25eaf2250be7d1a8408bf0c3d46e8a1

Issue Description:

    1. Current behavior:
      DocC rejects versions like 1.2.3-dev / 1.2.3-SNAPSHOT

Specifically it errors like this:

Error: '0.6.5-dev' is not a valid version string

    1. Expected behavior:

Some libraries, may want to make available docs for their nightly builds which are not tagged with “stable” versions but use some suffix like -SNAPSHOT or -dev.
In the server ecosystem we often have libraries stay around as -alpha or -beta or -dev for a while before they stabilize their APIs, but we DO want to be able to use them while in this state.

SwiftPM recognizes these versions and allows depending on them.

Specifically this is covered by sem-ver rule 9:

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.–.

I started poking at this, but sem-ver is actually quite a pain to parse properly manually.
Perhaps we should re-use code that SwiftPM has for this actually? I'll search around a little bit

@Kyle-Ye
Copy link
Collaborator

Kyle-Ye commented Oct 27, 2021

Do you mean `Version.swift` in SwiftDocC repo?

The SymbolKit seems solved it in `SemanticVersion.swift`

        /**
         * The major version number.
         *
         * For example, the `1` in `1.2.3`
         */
        public var major: Int
        /**
         * The minor version number.
         *
         * For example, the `2` in `1.2.3`
         */
        public var minor: Int
        /**
         * The patch version number.
         *
         * For example, the `3` in `1.2.3`
         */
        public var patch: Int


        /// The optional prerelease version component, which may contain non-numeric characters.
        ///
        /// For example, the `4` in `1.2.3-4`.
        public var prerelease: String?

        /// Optional build metadata.
        public var buildMetadata: String?

@d-ronnqvist
Copy link
Contributor

There are other version formats that we may want to support, especially for non-framework targets, so we may want to be even less strict about the version information and allow any string value.

That said, the version information isn’t currently used anywhere so we could also remove it now and add it back in the future when we have a need for that information.

@ktoso
Copy link
Member Author

ktoso commented Nov 4, 2021

> Do you mean `Version.swift` in SwiftDocC repo?

Right yeah. That seems to be what is used when we invoke.

SwiftPM also has a good semantic version type you're free to use believe https://github.com/apple/swift-tools-support-core/blob/main/Sources/TSCUtility/Version.swift (Checked with Boris from SwiftPM team)

@ktoso
Copy link
Member Author

ktoso commented Nov 4, 2021

> That said, the version information isn’t currently used anywhere so we could also remove it now and add it back in the future when we have a need for that information.

I mean, the docc page should definitely show what version of a package is documented, so I don't think removal is an option really.

@d-ronnqvist
Copy link
Contributor

I opened a PR here that keeps the version information but removes the requirements that it's formatted a specific way. #49

That way it could be presented somewhere while still giving developers the full flexibility to use any version format that they prefer.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 3, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements or enhancements to existing functionality
Projects
None yet
Development

No branches or pull requests

4 participants