[swift-build-dev] [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Maxim Veksler]

Hi guys,

Sorry for the late repose, Hope I haven't missed the review window.

I've read through the proposal for the versioning, and I feel that there is
an over complication there. I would suggest something like this for
specifying the version:


If you want to have latest version of SwiftyJSON (you don't even care about
when major version:

.package(url: "http://github.com/SwiftyJSON")


If you want to have latest of major 1

.package(url: "http://github.com/SwiftyJSON", from: "1")


if you want to have latest of minor 1.5

.package(url: "http://github.com/SwiftyJSON", from: "1.5)


if you want to specify exact 1.5.2 (but the author might choose to be
maintaining 1.5.2-patch1, 1.5.2-patch2 and co..)

.package(url: "http://github.com/SwiftyJSON", from: "1.5.2")



Adopting this structure I think removes the need to have a uptoNextMajor &
uptoNextMinor which behavior I find not intuitive.


-m.

On Mon, Mar 13, 2017 at 10:30 PM Rick Ballard via swift-evolution <
swift-evolution at swift.org> wrote:

>  Proposal link:
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
>
> Hi Xiaodi,
>
> Thanks for your review comments! There are indeed a few mistakes here;
> we're going to revise the proposal appropriately, and assuming that nothing
> else comes up to cause us to reject this proposal, it will wind up
> "accepted with revisions" tomorrow.
>
> Specifically:
>
> – .uptoNextMajor() and .uptoNextMinor were miscapitalized; we will correct
> them to .upToNextMajor() and .upToNextMinor().
>
> – Dave Sweeris' point about this reading wrong in English as
> .upToNextMajor("x.y.z") (vs. of "x.y.z".upToNextMajor) makes sense to us
> too. As a result, we're going to clarify this by changing it to
> .upToNextMajor(after:"x.y.z") and .upToNextMinor(after:"x.y.z").
>
> – We will get rid of .only() in favor of .exact().
>
> – We will remove the .package(url:,branch:) and .package(url:,revision:)
> initializers. They duplicate the functionality provided by the .branch()
> and .revision() cases without adding any additional value.
>
> – We are still planning to keep .package(url:,from:), however, even though
> it duplicates the functionality of the .upToNextMajor() case. The
> duplication is somewhat undesirable for the reason you mention, but we
> think it's worth it in this case for two reasons:
>
> * We want to encourage this form of version specification to be used when
> possible, to establish good norms around semantic versioning in our
> ecosystem. Calling it out as a special initializer makes it more prominent.
>
> * Since we hope that this form of version specification will be used most
> of the time, we still think that it's worthwhile to make it really quick
> and easy to type. Other package managers also have special syntax (e.g. ~>)
> to make the common version specifiers quick and easy. We want to stay
> swift-y and descriptive, but .upToNextMajor() is pretty annoying to type
> every time.
>
> - Rick
>
> On Mar 11, 2017, at 4:41 PM, Xiaodi Wu via swift-build-dev <
> swift-build-dev at swift.org> wrote:
>
> On Thu, Mar 9, 2017 at 12:34 AM, Ankit Aggarwal via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> +1, although I don’t know why we're supporting this:
>
> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", from: "1.5.8"),
>
> when, at least as far as I can tell, this:
>
> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8")),
>
> does the same thing, and the spelling is, at least to me, clearer as well.
> Dunno, maybe the “from” version is a term of art that I’m just not familiar
> with.
>
>
> Hi David,
>
> Thank you for the review.
>
> It is true that `from` and `.uptoNextMajor` are exactly same. We think
> that the most widely used requirement will be `.uptoNextMajor`, so we
> wanted to provide a shorthand for it.
>
>
> Kind of a late reply, but overall I think the proposal looks good with the
> exception of some of these `Requirement` vs. shorthand dichotomies. It
> looks like the following will be synonyms:
>
> ```
> .package(url: "/SwiftyJSON", branch: "develop")
> .package(url: "/SwiftyJSON", .branch("develop"))
> ```
>
> ...as well as...
>
> ```
> .package(url: "/SwiftyJSON", revision:
> "e74b07278b926c9ec6f9643455ea00d1ce04a021")
> .package(url: "/SwiftyJSON",
> .revision("e74b07278b926c9ec6f9643455ea00d1ce04a021"))
> ```
>
> It seems odd that there are two subtly different but equivalent ways to
> spell the same thing like that. But I get that there are possibilities for
> chaining made available with the latter notation and that the former was
> promised in a fairly new proposal that's been approved. Where it gets more
> unsatisfactory, IMO, is that
>
> ```
> .package(url: "/SwiftyJSON", .only("1.5.8"))
> .package(url: "/SwiftyJSON", .exact("1.5.8"))
> ```
>
> also seem to mean the same thing. Here, this is actively confusing,
> because every user will inevitably scratch their head trying to parse out
> the difference. I also share Dave's concern about
>
> ```
> .package(url: "/SwiftyJSON", from: "1.5.8")
> .package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8"))
> ```
>
> There is no intuition that would tell a user that the two are the same;
> after all, `uptoNextMinor` also starts "from" its argument. I understand
> that the latter is wordier, but it is not such a grave burden that the
> argument label couldn't be rewritten also as `uptoNextMajor`.
>
> While we're on the topic, the standard library spelling is `upTo` rather
> than `upto`, and while it's nitpicky I think it's important to go with the
> former given that "upto" is not a single word in standard English. If we
> wanted this to read more grammatically, consider also `.upToNextMajor(from:
> "1.5.8")`.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170313/1c532d60/attachment.html>