[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I do not agree with Ted that only a few projects should be ranked,
> everyone, as it is in npm should be available. Only be graded according to
> recommendations.
>
>
> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
>
>
> Clearly I’m double confused.  That meant to read “I’m not sure what
> comments of mine *you* are referring to”.
>
> I fully support having a broad spectrum of libraries that the community
> builds and uses.  Any library that we decide to make part of “core Swift” —
> IMHO at a mature point in a library’s evolution — would need to have high
> value to the majority of the community and would need to feel solid enough
> that we can lock it in for both source and binary compatibility, high
> quality of implementation with sustained maintenance, etc.
>

i mean I don’t think these approaches are incompatible. The “swift core”
could just make the process of independent libraries getting started
easier. Like right now there’s really no place to say “hey I just started a
library project for X, and anyone who wants to be involved should
contribute at Y github repo where it lives right now”. I’ve tried sending
that on this list before and it didn’t really work because mailing lists
aren’t really a good medium for that and no one wants the swift-evolution
list getting clogged with project-specific messages most people don’t care
about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171108/102ce4bb/attachment.html>