You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* seperate out registry requirement from source control requirement
* refactor manifet encoding and parsing to more clearly define dependency type and associated metadata
* make .upToNextMajor and .upToNextMinor extensions on Range<Version> to reuse across new requirment types
* adjust tests
Copy file name to clipboardExpand all lines: Sources/PackageDescription/PackageDescription.swift
-105Lines changed: 0 additions & 105 deletions
Original file line number
Diff line number
Diff line change
@@ -65,111 +65,6 @@ import Foundation
65
65
/// without having to update your package manifest and without losing access to
66
66
/// existing packages.
67
67
publicfinalclassPackage{
68
-
69
-
/// A package dependency of a Swift package.
70
-
///
71
-
/// A package dependency consists of a Git URL to the source of the package,
72
-
/// and a requirement for the version of the package.
73
-
///
74
-
/// The Swift Package Manager performs a process called *dependency resolution* to
75
-
/// figure out the exact version of the package dependencies that an app or other
76
-
/// Swift package can use. The `Package.resolved` file records the results of the
77
-
/// dependency resolution and lives in the top-level directory of a Swift package.
78
-
/// If you add the Swift package as a package dependency to an app for an Apple platform,
79
-
/// you can find the `Package.resolved` file inside your `.xcodeproj` or `.xcworkspace`.
80
-
publicclassDependency:Encodable{
81
-
82
-
/// An enum that represents the requirement for a package dependency.
83
-
///
84
-
/// The dependency requirement can be defined as one of three different version requirements:
85
-
///
86
-
/// **A version-based requirement.**
87
-
///
88
-
/// Decide whether your project accepts updates to a package dependency up
89
-
/// to the next major version or up to the next minor version. To be more
90
-
/// restrictive, select a specific version range or an exact version.
91
-
/// Major versions tend to have more significant changes than minor
92
-
/// versions, and may require you to modify your code when they update.
93
-
/// The version rule requires Swift packages to conform to semantic
94
-
/// versioning. To learn more about the semantic versioning standard,
95
-
/// visit [semver.org](https://semver.org).
96
-
///
97
-
/// Selecting the version requirement is the recommended way to add a package dependency. It allows you to create a balance between restricting changes and obtaining improvements and features.
98
-
///
99
-
/// **A branch-based requirement**
100
-
///
101
-
/// Select the name of the branch for your package dependency to follow.
102
-
/// Use branch-based dependencies when you're developing multiple packages
103
-
/// in tandem or when you don't want to publish versions of your package dependencies.
104
-
///
105
-
/// Note that packages which use branch-based dependency requirements
106
-
/// can't be added as dependencies to packages that use version-based dependency
107
-
/// requirements; you should remove branch-based dependency requirements
108
-
/// before publishing a version of your package.
109
-
///
110
-
/// **A commit-based requirement**
111
-
///
112
-
/// Select the commit hash for your package dependency to follow.
113
-
/// Choosing this option isn't recommended, and should be limited to
114
-
/// exceptional cases. While pinning your package dependency to a specific
115
-
/// commit ensures that the package dependency doesn't change and your
116
-
/// code remains stable, you don't receive any updates at all. If you worry about
117
-
/// the stability of a remote package, consider one of the more
118
-
/// restrictive options of the version-based requirement.
119
-
///
120
-
/// Note that packages which use commit-based dependency requirements
121
-
/// can't be added as dependencies to packages that use version-based
122
-
/// dependency requirements; you should remove commit-based dependency
123
-
/// requirements before publishing a version of your package.
124
-
publicenumRequirement{
125
-
case exactItem(Version)
126
-
case rangeItem(Range<Version>)
127
-
case revisionItem(String)
128
-
case branchItem(String)
129
-
case localPackageItem
130
-
131
-
varisLocalPackage:Bool{
132
-
if case .localPackageItem =self{returntrue}
133
-
returnfalse
134
-
}
135
-
}
136
-
137
-
/// The name of the package, or `nil` to deduce the name using the package's Git URL.
138
-
publicletname:String?
139
-
140
-
/// The location of the package dependency.
141
-
publicletlocation:String?
142
-
143
-
@available(*, deprecated, renamed:"location")
144
-
publicvarurl:String?{
145
-
get{
146
-
returnself.location
147
-
}
148
-
}
149
-
150
-
/// The registry identity of package dependency.
151
-
publicletidentity:String?
152
-
153
-
/// The dependency requirement of the package dependency.
154
-
publicletrequirement:Requirement
155
-
156
-
/// Initializes and returns a newly allocated requirement with the specified url and requirements.
0 commit comments