Hi Jay,
> On Oct 16, 2016, at 7:14 PM, Jay Abbott <[email protected]> wrote:
>
>
> I like the core idea here, but I feel that it could potentially prevent teams
> updating, through focus on other things and general laziness/ignorance to
> what's going on with external dependencies. Although this gives me a separate
> idea...
I hope to tackle this through features which will help notify you when new
versions you could upgrade to are available. I hope the default practice in the
ecosystem will then become to heed those notifications and update.
> How about an additional feature that can be run manually if desired, or more
> likely run as a daily/overnight job on CI. I'm not entirely sure what the
> command would be or how it would work exactly, but the general idea would be:
>
> * Build a list of dependencies that can potentially be updated (from the
> entire dependency graph).
> * For each updatable dependency in the list {
> * Keep all the other pins as-they-were and fetch the updated dependency.
> * Build the project and run its tests.
> * Keep track of which ones worked and which ones failed.
> }
> * If there are updatable dependencies that build successfully, and all (your
> project) tests still pass - this can to be reported to the development team.
>
> This way, teams could use pinning and automate checking for compatible
> updates. Also package owners could potentially be notified (with explicit
> consent of their users) if they broke compatibility in what should have been
> a compatible release. I realise that not everything going on here is inside
> the remit of a package manager, but the package manager could provide
> functionality to help with such things, a bit like git-bisect. Then again,
> the SPM community proposal seems to cast quite a wide potential remit.
>
> An additional cool feature would be some mechanism to allow notifications to
> the package owner if what they have released as compatible (according to the
> version) actually isn't. Explicit opt-in from users for this one of course,
> with options for what information to include. Maybe swift.org
> <http://swift.org/> could host this for package owners, and usage stats for
> them too?
Both of the features you propose make a lot of sense to me, and are things I
definitely would like to see us do in time.
For now, though, I see this feature as a "building block" towards those
directions. Others can build on top of this feature to create automated systems
like the ones you describe, I don't think we need to try and tackle everything
ourselves in the initial proposal.
- Daniel
>
> On Sun, 16 Oct 2016 at 18:06 Georgios Moschovitis via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> > In Swift, we have pretty consistently tried to choose the "right" answer to
> > make the resulting language consistent and beautiful.
> > I'm perfectly happy to have a discussion about the naming, but I would like
> > it to be driven by what we believe the "right" answer is, not simply by
> > deference to existing solutions.
>
> +100
>
> Moreover, after your explanation, `lock` feels wrong to me too.
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
