- 18 Jan, 2018 1 commit
-
-
Samuel Giddins authored
-
- 17 Jan, 2018 1 commit
-
-
Samuel Giddins authored
This resolves a (potential) ordering bug due to pre-releases. In #possibility_versions_for_root_name, we check whether dependencies on a pod are pre-release or external source, and if so allow pre-releases. It is crucial, therefore, that any external source dependencies have been addressed before any transitive source without the external source, so that pre-releases are (properly) allowed.
-
- 13 Jan, 2018 4 commits
-
-
Samuel Giddins authored
[Resolver] Fix multi-source resolution
-
Samuel Giddins authored
-
Samuel Giddins authored
-
Samuel Giddins authored
-
- 10 Jan, 2018 3 commits
-
-
Dimitris Koutsogiorgas authored
Do not include test spec resource and framework paths of external targets into scripts
-
Dimitris Koutsogiorgas authored
-
Dimitris Koutsogiorgas authored
-
- 20 Dec, 2017 5 commits
-
-
Dimitris Koutsogiorgas authored
Show warning when Pod source uses unencrypted HTTP
-
Dimitris Koutsogiorgas authored
Restore `development_pod_targets` public method in installer
-
Dimitris Koutsogiorgas authored
-
Felix Krause authored
-
Felix Krause authored
-
- 18 Dec, 2017 2 commits
-
-
Dimitris Koutsogiorgas authored
Fix build
-
Dimitris Koutsogiorgas authored
-
- 17 Dec, 2017 3 commits
-
-
Danielle Tomlinson authored
-
Danielle Tomlinson authored
-
Danielle Tomlinson authored
-
- 12 Dec, 2017 2 commits
-
-
Dimitris Koutsogiorgas authored
Set development pods' podspecs syntax to Ruby when appropriate
-
Eric Amorde authored
-
- 06 Dec, 2017 4 commits
-
-
Dimitris Koutsogiorgas authored
Fix duplicate framework/resource output paths caused by the same output file name
-
Eric Amorde authored
Fix duplicate framework and resource output paths caused by the same output name but different source for each configuration
-
Dimitris Koutsogiorgas authored
Allow installation of a pod with its own Swift version on multiple targets
-
Dimitris Koutsogiorgas authored
-
- 05 Dec, 2017 9 commits
-
-
Dimitris Koutsogiorgas authored
Show warning when SDK provider tries to push a version with an unencrypted HTTP source
-
Dimitris Koutsogiorgas authored
Add information about how to run tests
-
Felix Krause authored
This is something that took me a few minutes to find, so let's make it easier for new people to know how to run a specific test, as that's very commonly used when preparing a PR. As there is a lot of potential small changes in this PR, please feel free to directly apply any changes and merge from there.
-
Felix Krause authored
-
Felix Krause authored
-
Felix Krause authored
-
Felix Krause authored
-
Dimitris Koutsogiorgas authored
Integrate `swift_version` DSL support into pod targets
-
Dimitris Koutsogiorgas authored
-
- 03 Dec, 2017 1 commit
-
-
Felix Krause authored
-
- 02 Dec, 2017 4 commits
-
-
Felix Krause authored
-
Felix Krause authored
-
Felix Krause authored
-
Felix Krause authored
-
- 01 Dec, 2017 1 commit
-
-
Felix Krause authored
Related to https://github.com/CocoaPods/CocoaPods/pull/7249, fixes https://github.com/CocoaPods/CocoaPods/issues/7238 I'll add tests, once I get the ok that this is the right location and the right approach. For now I used the `error` method to fail the validation. I believe that it's the right thing to do, there is no good excuse to transfer executable over non-encrypted protocols, however I do understand that this might throw off some SDK providers, and them being overwhelmed when they quickly need to push an update. You all have more context around what the users are like, and if they have a way to work around this, just let me know what you're deciding on
👍
-