Add evolution ideas page

Author: aciidgh

Documentation/EvolutionIdeas.md

@@ -0,0 +1,205 @@
+# Swift Package Manager Evolution Ideas
+
+This is a list of some evolution ideas for the package manager. Once the details
+of an idea are fleshed out and there is a full proposal, it can be scheduled for
+the swift-evolution process. It is important to note that not every idea on this
+list is guaranteed to become an official feature, and it all depends on where
+the design discussion leads us. Also, this is not meant to be an exhaustive
+feature list, if you have an idea for a feature that you think will be
+a valuable addition to the package manager, feel free to start a discussion
+about it.
+
+If you're interested in participating in a particular evolution idea, please
+familarize yourself with the existing discussion on that topic and start
+participating in the discussion thread of that idea. If a thread doesn't exist
+for that idea, please start one with a [draft
+proposal](https://github.com/apple/swift-evolution/blob/master/proposal-templates/0000-swiftpm-template.md)
+that can be used as a starting point.
+
+**Important Note**: This list is not in any particular order. I plan to keep
+this post updated but please let me know if you see something out-of-date.
+
+# Mirror and Fork Support
+
+You may want an easy way to mirror or fork specific packages in your package
+graph. This could be useful if you want to make a private customization to
+a package that you depend on, or even if you just want to override the origin
+repository of your packages so that you can fetch from a private mirror and not
+depend on the original repository always being there.
+
+Thread: https://forums.swift.org/t/dependency-mirroring-and-forking/13902
+Bug: [SR-679](https://bugs.swift.org/browse/SR-679)
+
+# Build Settings
+
+Some packages require specific language or linker flags that SwiftPM doesn’t
+currently support, and some packages may desire other configurable properties as
+well.  We want to have a real robust "build settings" model for adding these
+kinds of properties, potentially including including conditional settings and
+fine-grained control over what parts of the package use which property values.
+
+Thread: N/A  
+Bug: [SR-3948](https://bugs.swift.org/browse/SR-3948)
+
+# Conditional Dependencies
+
+Packages may want to use dependencies that they only use while testing the
+package. Such dependencies shouldn't take part in dependency resolution process
+when a package is being used as a dependency. This is also called test-only or
+development dependencies in other package managers. It is sometimes also
+required to declare platform-specific dependencies which should be only fetched
+when a package is being built for a certain platform. This is currently possible
+using `#if os` checks but it leads to two problems: 1) it forces
+a non-declarative syntax in the manifest file, and 2) it causes issues in
+maintaining the `Package.resolved` file as the dependency is added or removed
+depending on the platform.
+
+Thread: N/A  
+Bug: [SR-883](https://bugs.swift.org/browse/SR-883)
+
+# Resource Support
+
+The Swift package manager needs a story for how packages should specify their
+resources to include with products.
+
+Thread: N/A  
+Bug: [SR-2866](https://bugs.swift.org/browse/SR-2866)
+
+# Extensible Build Tools
+
+Many users want to incorporate a variety of build-time tools into their
+packages, whether to support a custom language or preprocessor, or to add their
+own documentation generator or linter. SwiftPM could add extensibility to
+support tools packages which could bring these steps to the build process.  We
+expect this behavior to greatly enhance our capacity for building complex
+software packages.
+
+One important thing for us to be careful about here is to make sure that all
+parts of the build process still clearly declare their inputs and outputs to
+SwiftPM, so that it can make sure that they behave correctly and perform well
+for incremental and parallel builds.
+
+
+Thread: https://forums.swift.org/t/package-manager-extensible-build-tools/10900
+Bug: N/A
+
+# User-defined Template Support
+
+It would be nice if users can hook into the init command to add custom templates
+that they frequently use. 
+
+Thread: N/A  
+Bug: [SR-7837](https://bugs.swift.org/browse/SR-7837)
+
+# Documentation Generation Support
+
+We can leverage SourceKit to extract documentation information from Swift
+packages that can be further transformed into a developer consumable format like
+a static HTML website.
+
+Thread: N/A  
+Bug: N/A
+
+# Tagging and Publishing support
+
+Today you publish new versions of your package by tagging manually with git, and
+you use git directly to view your published tags. SwiftPM could help automate
+this process, performing any validation, housekeeping, or auxiliary tasks that
+might make sense as part of a streamlined and safe publication workflow.
+
+Thread: N/A  
+Bug: N/A
+
+# Install/deploy Command
+
+When you’re deploying the product of your package, whether to a server or your
+local system, it could be helpful for SwiftPM to provide support for automating
+that process. You may want to configure layout and library linkage aspects of
+your products for your specific deployment environment, record version
+information about what your products were built from, and otherwise leverage the
+context that SwiftPM has about your packages for a seamless deployment
+experience.
+
+Thread: N/A  
+Bug: N/A
+
+# Performance Testing Support
+
+Currently, SwiftPM has no support for running performance tests. We need to
+provide a way to specify performance tests for a package and to run them from
+the SwiftPM command-line tools.
+
+[Here](https://github.com/aciidb0mb3r/swift-evolution/blob/pref-proposal/proposals/xxxx-package-manager-performance-testing.md) is a very old draft proposal that I haven't gotten around to post for discussion yet.  
+
+Thread: N/A  
+Bug: [SR-1354](https://bugs.swift.org/browse/SR-1354)
+
+# Support for External Testing Frameworks
+
+Currently, SwiftPM only supports writing tests with help of XCTest testing
+framework. The community should be able to use any testing framework of their
+choice to test with SwiftPM. This feature will most likely depend on extensible
+build tools feature.
+
+Thread: N/A  
+Bug: N/A
+
+# Package Index
+
+SwiftPM plans to have a real index for Swift packages some day. In addition to
+defining a namespace for package names and providing easier package discovery,
+it could even support metrics for quality, such as automated test coverage
+statistics, or ways to evaluate the trustworthiness of packages that you’re
+considering using. This will be a large project.
+
+Thread: N/A  
+Bug: N/A
+
+# Multi-Package Repository Support
+
+Currently the package manager requires that each package live at the root of
+a Git repository. This means that you can't store multiple packages in the same
+repository, or develop packages which locate each other in a filesystem-relative
+manner without relying on Git. We need a proposal for how we would like to
+support this.
+
+Thread: N/A  
+Bug: [SR-3951](https://bugs.swift.org/browse/SR-3951)
+
+# Cross-platform Sandboxing
+
+Sandboxing is one way to help prevent `Package.swift` manifest evaluation and
+builds from escaping out into your system, either accidentally or deliberately.
+SwiftPM uses macOS's sandboxing technology already, but it would be great to
+bring this safety to other platforms.
+
+Thread: N/A  
+Bug: N/A
+
+# Automatic Semantic Versioning
+
+Automatically detecting what semantic version it looks like you should be
+publishing your changes with could be very helpful for package authors. SwiftPM
+could do this by analyzing the source code's API to see what has changed and
+whether the API is backwards-compatible, at least at compile time.
+
+Thread: N/A  
+Bug: N/A
+
+# Machine-Editable Package.swift
+
+We need an easy way to edit the Package.swift manifest from automated tools, for
+cases where you don't want users to have to update the Swift code directly.  We
+think that it's possible to provide API to allow this, probably using
+[`SwiftSyntax`](https://github.com/apple/swift/tree/master/tools/SwiftSyntax).
+
+Thread: N/A  
+Bug: N/A
+
+# SwiftPM Integration in Xcode
+
+This is not part of the evolution ideas but it has frequently come up on the
+forums (albeit for the right reasons). Please see [this](https://forums.swift.org/t/swift-package-manager-3-0-project-status/3794/5)
+post if you haven't. It is important to understand that Xcode is **not** part of
+the Swift Open Source project and the future plans and timelines are not published 
+in public.  Please use Apple developer [forums](https://developer.apple.com/devforums/) or [bug reporter](https://developer.apple.com/bug-reporting/) for Xcode related discussions.