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

[Kyle-Ye]

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]

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]

> 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]

> 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]

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.