Merge pull request #49 from stevengill/templates
added new template proposal
diff --git a/README.md b/README.md
index 3eea5d5..e7a039f 100644
--- a/README.md
+++ b/README.md
@@ -14,12 +14,13 @@
## In Progress Proposals
| Proposal | Status/Notes
|----------|-------------------
-| [Nightly Builds for Cordova and platforms](https://github.com/cordova/cordova-discuss/pull/47) | Proposed |
+| [Templates in Cordova CLI Part 2](https://github.com/cordova/cordova-discuss/pull/49) | Proposed |
## Completed Proposals
| Proposal | Status/Notes
|----------|-------------------
+| [Nightly Builds for Cordova and platforms](proposals/NightlyBuilds.md) | Completed |
| [Templates in Cordova CLI](proposals/CLI-Templates.md) | Completed |
| [Cordova platform API](cordova-lib refactoring\Cordova-lib refactoring proposal.md) | Completed |
| [Cordova Face2Face Oct 2015 meeting](proposals/Face2Face-Oct15.md) | Meeting held Oct 15 - completed |
@@ -32,5 +33,6 @@
| [Add Telemetry to Cordova CLI](proposals/Telemetry.md) | In Progress
| Ideas for improving documentation [[1]](proposals/ImprovedDocumentation.md) [[2]](proposals/ImproveCordovaDocumentation.md) | Most of the recommendations completed |
| [CI for PRs submitted for cordova plugins](proposals/ci-for-plugin-prs.md) | Completed
+| [Unified cordova-fetch proposal](https://github.com/cordova/cordova-discuss/blob/master/proposals/fetching.md) | Completed
diff --git a/proposals/NightlyBuilds.md b/proposals/NightlyBuilds.md
new file mode 100644
index 0000000..141265b
--- /dev/null
+++ b/proposals/NightlyBuilds.md
@@ -0,0 +1,52 @@
+# Cordova nightly builds proposal
+
+We'd like to complete the work, started by @stevesgill in [CB-7904](https://issues.apache.org/jira/browse/CB-7904) and get nightly builds of cordova and related packages published on NPM.
+
+## Background
+
+Currently the only way to test the development version of cordova is to clone cordova and all dependent repos, link them to each other and npm install every cordova repository, which is pretty complicated. Using `cordova-coho` tool makes the process of setting up development cordova version a bit easier, but there is still a lot of caveats.
+
+Having development version of cordova published on npm would allow everyone to easily set up development version of cordova to test unreleased features, reproduce the bugs or confirm they get fixed in current version.
+
+Nightly builds in our understanding are an npm packages created from current 'master' branches of respective repos and available on NPM under `nightly` dist tag (`next` tag should be available as well and aliased to `nightly` ), so they easily could be installed like `npm i cordova@nightly`. All appropriate dependencies of nightly packages also will be updated to point to their nightly versions, e.g. `cordova-cli@6.2.0-nightly` will depend on `cordova-lib@6.2.0-nightly`, etc.
+
+The nightly version of cordova-lib will also have main platform pinned to their nightly versions, so `cordova install android` will automatically install `cordova-android@nightly` to allow early adopters test new features and bugfixes in platforms.
+
+The full format of nightly version is `<package_id>@<next_version>-nightly.<build_date>.<commit_SHA>`, for example:
+
+```
+cordova-lib@6.2.0-nightly.2016.05.12.16498003
+```
+
+This format is fully Semver-compatible and allows to us to easily recreate the same the cordova setup locally
+
+The nightly packages, we're planning to release, include Cordova tools (cordova-cli, cordova-lib, etc.) and the major platforms (Android, iOS, Windows)
+
+## How it will work
+
+All the aspects of creating and publishing nightly builds are automated using `cordova coho` command. Running `coho nightly` assumes the following steps:
+
+1. For every package to publish update respective repo to the latest commit
+2. For every package determine if there are any changes present since last nightly and if not - exclude that package from release. This step is required since we can't do automated unpublish of releases older than 1 day, so we need to do release only for actual changes to keep `npm view versions` list clean.
+
+2. For every package update version to nightly version
+ - Also update dependencies versions to point to nightly versions of other `cordova-*` dependencies
+ - Also update bundled dependencies - 'npm link' corresponding repos
+3. For every package run the tests to make sure that release will not contain any known bugs
+4. Publish packages on NPM under `nightly` dist tag
+
+The `cordova coho` command also accepts `--pretend` options to run these steps locally without publishing packages to NPM
+
+## Current status
+
+The work is currently in progress and the following items are completed:
+
+1. The [Jenkins job](https://builds.apache.org/view/A-D/view/Cordova/job/cordova-nightly/) that has npm set up using credentials for publishing packages
+2. The [update](https://github.com/apache/cordova-coho/pull/116) for `coho nightly` that supports publishing of 'cordova-cli' and `cordova-lib`
+3. Patches for `cordova-cli` and `cordova-lib` that fixes some tests that were failing when were running on nightly builds
+4. Support for [building arbitrary repos](https://github.com/apache/cordova-coho/pull/122) has been added.
+5. Support for [building nightlies for platforms](https://github.com/apache/cordova-coho/pull/124) has been added.
+
+## Next steps
+
+- [] Update cordova to print necessary warnings and information about nightly versions of dependencies and platforms when running `cordova --version` and `cordova platform ls`
diff --git a/proposals/ThirdPartyPackageManagers.md b/proposals/ThirdPartyPackageManagers.md
index 3ace1d2..6d2727e 100644
--- a/proposals/ThirdPartyPackageManagers.md
+++ b/proposals/ThirdPartyPackageManagers.md
@@ -19,7 +19,7 @@
<engine name="nuget" version=">=3.2" platform="windows" />
</engines>
-<framework src="path/to/mypod.podspec" type="podspec" />
+<framework src="name_of_cocoapod" type="podspec" spec="~> 1.1.2"/>
<framework src="path/to/mynu.nuspec" type="nuspec" />
```
@@ -32,3 +32,14 @@
## Framework Tag
The `src` attribute can be a relative path or a URL. The `type` attribute specifies the type of framework that corresponds to the `engine` supported. In this case type `podspec` means that the lib should be installed using the `cocoapods` package manager, and `nuspec` for the `nuget` package manager.
+
+## Spec Argument
+
+The `spec` arugment will specify the version of the CocoaPod that is to be used. `~>` is CocoaPod's optimistic operator-- copied from [CocoaPods docs](http://guides.cocoapods.org/using/the-podfile.html):
+ - '~> 0.1.2' Version 0.1.2 and the versions up to 0.2, not including 0.2 and higher
+ - '~> 0.1' Version 0.1 and the versions up to 1.0, not including 1.0 and higher
+Cocoapods also support logical operators:
+ - '> 0.1' Any version higher than 0.1
+ - '>= 0.1' Version 0.1 and any higher version
+
+The string passed in the `spec` argument will be pasted into the Podfile.
diff --git a/proposals/fetching.md b/proposals/fetching.md
new file mode 100644
index 0000000..c69164b
--- /dev/null
+++ b/proposals/fetching.md
@@ -0,0 +1,59 @@
+# Unified Cordova Fetching Proposal
+- Status: Completed
+
+### Current
+
+Three existing fetching implementations.
+
+1. Platform Fetching
+ - Platform.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/platform.js#L258
+ - Lazy Load https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/lazy_load.js
+
+2. Plugin Fetching
+
+ a) cordova plugin fetching
+ - plugin.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/plugin.js#L147
+ - fetch.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plugman/fetch.js
+ - registry.fetch https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plugman/registry/registry.js#L123
+ b) plugman plugin fetching
+ - install.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plugman/install.js
+ - possiblyFetch https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plugman/install.js#L104
+ - fetch.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plugman/fetch.js
+ - registry.fetch https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plugman/registry/registry.js#L123
+
+3. Template Fetching
+ - create.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/create.js#L167
+ - remote load https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/remote_load.js
+
+Both lazy load and remote load use gitclone.js https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/gitclone.js
+
+Currently, platforms and templates are cached at `~/.cordova/lib/npm_cache/PACKAGE`. On master, plugins are being cached to `~/.npm/PACKAGE`.
+
+### Proposal:
+
+* Create a new module named `cordova-fetch`. Fetches from npm and git.
+* Start using system installed `npm` instead of packaging our own `npm` in `cordoba-lib`. We already check for `git` being installed, we should do the same for `npm`. We would use `superspawn` to shell out to the system `npm`.
+* Stop using `.cordova/lib/npm_cache/`. Modules instead get fetched to root `node_modules` directory in your applications
+* Add new `--fetch` flag to `cordova` and `plugman` to use `cordova-fetch` over existing fetching methods
+* Plugin/platform removal should run `npm uninstall` on your cordova projects to remove the module from the apps `node_modules` directory.
+* if a `package.json` exists, adding `--save` will also add the dependency to `package.json` (as well as to `config.xml`). This won't be used until a future update is made to move save functionality from `config.xml` to `package.json`. Just adding it now for future proofing.
+* Add `--fetch` flag to `cordova create APPID --template TEMPLATEID/GITURL` to use cordova-fetch when getting the template. The template is fetched to `.cordova/node_modules/` directory and the appropriate files are added.
+
+### New Requirements
+
+* Have to remove support for installing plugins/platforms from git subdirectoires. https://cordova.apache.org/docs/en/5.0.0/guide/cli/#advanced-plugin-options. I recommend we add deprecation notices for this ASAP.
+* Every plugin, platform and template requires a `package.json`
+
+### Quirks
+
+* Currently, I am using a diff of `npm ls` to determine which module was just installed. This is because the user can pass in a git url as a target to `cordova-fetch`. If the git url repo-name is different than the `package.name`, only way to get what module was just installed is by doing a diff before and after the installation. The diffing technique can fail if the user is adding a module that has already been npm installed. Luckily cordova doesn't allow adding platform/plugin which has already been added. cordova platform/plugin rm will also remove the module from the applications `node_modules` directory.
+* As a fallback to the diffing method, I am taking the target or repo-name as the module name. Hopefully this won't be needed.
+
+### Future goals
+
+* add a package.json to cordova projects, update `cordova` to start using `package.json` as well as `config.xml`. This requires moving over some functionality from `config.xml` and updating tools to look in `package.json` before checking `config.xml`.
+
+### Links
+Issues: https://issues.apache.org/jira/browse/CB-9858 & https://issues.apache.org/jira/browse/CB-11349
+
+
