rougeware / swift-semver Goto Github PK

A small Swift library that implements SemVer 2.0.0. This is designed to be simple to use and to easily fit into any Swift codebase.

License: Other

Swift 100.00%

semver semantic-versioning swift swift-package-manager swift-package swift-server spm swiftpackage swiftpackagemanager semantic-version

swift-semver's Introduction

Swift Semantic Versioning

A small library that implements SemVer 2.0.0. This is designed to be simple to use and to easily fit into any Swift codebase.

Examples

Let's say you have a release candidate of version 2.0 of your app. The following are all equivalent:

_ = SemVer(major: 2, minor: 0, preRelease: ["RC", 1])
_ = SemVer(2,0,0, preRelease: ["RC",1])
_ = SemVer("2.0-RC.1")
_ = SemVer("2.0.0-RC.1")

These can also be compared using Swift comparison operators. For instance, all these are true:

SemVer("2.0") == SemVer("2.0.0")
SemVer("1.2.0") < SemVer("2.0.0")
SemVer("1.2.0") <= SemVer("2.0.0")
SemVer("12.0") > SemVer("2.9.9")

Since this conforms to Semantic Version 2.0.0, attempting to use an invalid semantic version as a string will result in a nil object:

nil == SemVer("Obviously Bad")
nil == SemVer("1")
nil == SemVer("-2.0")
nil == SemVer("2.0-β")
nil == SemVer("2.0-beta_1")
nil == SemVer("1.-2")
nil == SemVer("1.2.-3")
nil == SemVer("1.2.3.4")

License

This is licensed under BH-1-PS Opus 2.

swift-semver's People

Contributors

Stargazers

Watchers

Forkers

ios-swift-controls bcardarella

swift-semver's Issues

Enforce increment-only semantic versions

One feature of this library is that it helps you mutate the semantic version; this is why it's never been a static value.

To increase this assistance, instances should enforce that changing a semantic version's MAJOR/MINOR/PATCH values only results in increments, as per SemVer rule 2:

Each element MUST increase numerically

Finish documenting

Documentation is almost complete, but there are lines like this:

    /// The PATCH version; increment this when you

And some undocumented fields like:

    public var preRelease: PreRelease?
    public var build: Build?

It's over a year out, and Swift 5 is an easy migration path. If you're reading this and you're sad that this package doesn't support Swift 4, feel free to use an older release; it's been good since day 1 🙂

Conform to `Hashable`

Semantic versions should be usable as keys in a hash table

Make patch non-Optional

In the official SemVer spec, PATCH is non-optional, but in this implementation, it is Optional. There is some ongoing discussion about whether PATCH should be optional, but for now it is not.

Major, Minor, Patch, & Pre-Release identifiers doesn't behave per spec: these numeric identifiers MUST NOT include leading zeroes.

According to the spec:

Numeric identifiers MUST NOT include leading zeroes.

However, SemVer(1,0,0, preRelease: "01") and SemVer("01.02.03") are allowed; it should result in nil, but instead it initializes just fine.

When fixing, this restriction should also apply to mutating the pre-release.

Add fancy shields to README

Everyone loves shields!

Update license

It's time to move from BH-1-PS Opus 2 to BH-1-PS Opus 3

Make it a Swift Package! 📦

This repo should be available to Swift Package Manager as a Swift Package

Set up GitHub action

This will provide a nicely convenience CI way to test this with every PR.

Pairs nicely with #11

Move conveniences to another package or something

Conveniences.swift is not related to semantic versioning. Either make it all private or move it to a separate Swift package

Add comparison function which ignores PATCH/MINOR

It'd be nice to do a comparison to see if 1.2.3 matches 1.2.x andor 1.x.x (up-to-next patch & up-to-next minor)

Declare conformance to `LosslessStringConvertible`

All the requirements are there; it just needs to be declared

10.0 < 11.0 && 10.0 > 11.0

This should fail, but it does not:

let v10_0 = SemVer(10,0)
let v11_0 = SemVer(11,0)
assert(v10_0 < v11_0
    && v10_0 > v11_0)

This seems to be because isAscending(_:_:isLessThanNil:) erroneously returns true if both arguments are nil

Likely will be resolved with #5

Conform to Codable

It makes a lot of sense to be able to en- and de-code a SemVer, since the spec is just a string, and string parsing is already built

Write tests that formalize the spec

Basically turn semver.org into Swift tests