Use Version type from SwiftPM #2670
Conversation
| expect(Version.from(PinnedVersion("1.4")).value) == Version(1, 4, 0) | ||
| expect(Version.from(PinnedVersion("v2.8.9")).value) == Version(2, 8, 9) | ||
| expect(Version.from(PinnedVersion("2.8.2-alpha")).value) == Version(2, 8, 2, prereleaseIdentifiers: ["alpha"]) | ||
| expect(Version.from(PinnedVersion("2.8.2-alpha+build234")).value) == Version(2, 8, 2, prereleaseIdentifiers: ["alpha"], buildMetadataIdentifiers: ["build234"]) |
There was a problem hiding this comment.
Line Length Violation: Line should be 160 characters or less: currently 162 characters (line_length)
mdiep
force-pushed
the
use-versions-from-swiftpm
branch
3 times, most recently
from
32b336f
to
c18dbca
Compare
|
Integration tests are failing due to warnings because libSwiftPM is built as a dynamic library. I've asked if this is necessary. We'll have to wait on that before proceeding here. |
mdiep
force-pushed
the
use-versions-from-swiftpm
branch
2 times, most recently
from
78363b2
to
7d216ea
Compare
| @@ -1,5 +1,8 @@ | |||
| import Foundation | |||
| import Result | |||
| import Utility | |||
|
|
|||
| import struct Foundation.URL | |||
There was a problem hiding this comment.
This disambiguation is necessary because Utility defines its own URL type.
mdiep
force-pushed
the
use-versions-from-swiftpm
branch
3 times, most recently
from
885dd9c
to
979d0a5
Compare
mdiep
force-pushed
the
use-versions-from-swiftpm
branch
from
979d0a5
to
a8f42b0
Compare
|
I'm not sure why this is failing on CI. The tests always pass locally and I did get one green build. 😕 |
mdiep
force-pushed
the
use-versions-from-swiftpm
branch
from
d8f5853
to
1ce8c62
Compare
| @@ -24,7 +18,7 @@ matrix: | |||
| env: JOB=CI_TEST_10_1 | |||
| - os: osx | |||
| language: objective-c | |||
| osx_image: xcode9.4 | |||
| osx_image: xcode10.1 | |||
There was a problem hiding this comment.
I am a little confused now as what version of Xcode we required to build.
Requiring 10.1 cuts out High Sierra homebrew builds
There was a problem hiding this comment.
This PR would raise the requirement from 9.4 to either 10.0 or 10.1. BUT our deployment target is still 10.10, so you only need a newer OS to build. (And I think you could build on an older OS if you installed a newer swift first.)
SwiftPM's master requires Swift 4, which is the reason for this change.
We're using master because I had to submit a PR to add a static library version of SwiftPM. I could do that on a fork of SwiftPM against an older release, but I think we'll want to get more changes from SwiftPM master.
I think that building off of SwiftPM is a big enough advantage that dropping support for building on 10.11 isn't a big deal. But I'm open to other opinions here. @Carthage/carthage
There was a problem hiding this comment.
dropping support for building on 10.11 isn't a big deal.
We don't have statistics so it's hard to say. I for one just updated last week since in my organization's IT department wouldn't let us.
Once this is released we effectively cut out whoever is relying on homebrew but on 10.10.
We could release a one time alternative formula of Carthage (cathage@0.31.2) at the current version which would still allow homebrew builds of 0.31.2.
There was a problem hiding this comment.
Shouldn't people be able to install older versions of Carthage already?
If you're on an older OS, you have to use older toolchains anyway, so there shouldn't be a pressing need to upgrade your Carthage. And since you could install through the pkg installer, I'm not bothered by it—you can still upgrade if you need to.
I know this is potentially inconvenient, but I think the wins from building off of SwiftPM are too great not to move forward with this.
There was a problem hiding this comment.
I'm not suggesting to hold back at all :)
Sure the .pkg works but I think we can still keep the convenience offered by homebrew by adopting the practice of releasing an end-of-support formula every time a version of Xcode requires an OS update (which is in itself annoying) .
There was a problem hiding this comment.
Depends on #2665.
This is the first step in building more off of SwiftPM. I think if we do this, then use their equivalent of
VersionSpecifier, we can start readingPackage.resolvedand/or using the Swift PM resolver. Using common types will make those things easier.