I didn’t reply to all before... um, That’s a very good point.
Still, I’d like the rules to be as clear as possible. That only helps :) Another point I forgot to mention, Kelvin: Jazzy ( https://github.com/realm/jazzy/blob/master/README.md) derives documentation from the comments. We can use that in the index :) On Tue, Nov 7, 2017 at 6:18 PM Kelvin Ma <kelvin1...@gmail.com> wrote: > On Tue, Nov 7, 2017 at 3:15 PM, Félix Fischer <felix9...@gmail.com> wrote: > >> On Tue, Nov 7, 2017 at 5:24 PM Wallacy <walla...@gmail.com> wrote: >> >>> The Compatibility Suite is a good start, but I agree that something a >>> bit more centralized has its benefits. >>> >>> To be perfect, Compatibility Suite and Swift Package Manager need to >>> work "together" to offer something simple like nodejs npm and a friendly >>> (and central) interface to not only find these projects. Something more >>> similar to nuget too. >>> >>> The only thing I miss using npm and nuget is some kind of "compromise" >>> with maintenance. And also some commitment to (avoid) rework. Several >>> projects remake something that another does also without explaining well >>> the differences between them. >>> >>> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in >>> project like Compatibility Suite with steroids. Not only to track those >>> projects, but in some level help defining some standards, documentations, >>> versioning etc. This can be done entirely within the community. >>> >>> Not so similar, however the gstreamer keeps a list of "base", "good", >>> "ugly" and "bad" plugins for similar reasons. >>> >>> We can do something in this line of reasoning: >>> - A central repository for projects (like Compatibility Suite) >>> - A tool to find and add each project (like SwiftPM) >>> - Rules for joining (like Compatibility Suite) >>> - A classification for each repository (like gstreamer) >>> - A good way to make each project as small and direct as possible (to >>> take advantage of cross-module inlining / specialization) >>> - A list of discussion (or a forum?) for people that maintain (or have >>> an interest in maintain) projects in this "official" list. >>> >> >> I like this approach much more. Feels more natural. And a forum >> (piggybacking on the eventual Discourse perhaps). I’d only change two >> things and extend one: >> >> - Instead of “central repository”, a “central index”. It makes it more >> transparent, more distributed, and closer to the current reality. >> >> - Here: >> >> >>> I vote for empowering SwiftPM and Compatibility Suite instead a >>> "Non-Standard Libraries". >>> >>> >> I agree with a central index, but as Kelvin says, we shouldn’t be using >> the Compat Suite directly because of GPL issues. >> >> - I’d extend on the “Rules for Joining” point: they should be as clear >> and explicit as possible, to avoid drama like the one episode that happened >> last year on the JS repositories with that string-padding library. That >> thing broke half of the internet for some hours, and it was all about >> something unclear in the rules, if I remember the case correctly. >> > > I think Swift is less vulnerable to that than node.js if anything because > Swift is compiled ahead of time so someone removing their repo doesn’t > instantly break everything else. > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution