Merge master into janpio-docs_cleanup
diff --git a/docs/README.md b/docs/README.md
index d389f84..d9fc430 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -35,20 +35,9 @@
### About Releases
-* [Versioning and release strategy](versioning-and-release-strategy.md)
* [Release Voting](release-voting.md)
* [Setting up GPG](setting-up-gpg.md)
-## Committer Workflow
-
-Things a committer frequently does:
-
-* [Committer workflow](committer-workflow.md)
-* [Code Reviews](code-reviews.md)
-* [Processing Pull Requests](processing-pull-requests.md)
-* [Triaging JIRA issues](jira-triage.md)
-
## Misc
-* [Storing Repo Versions Design](storing-repo-versions-design.md)
* [Access to Apache's jenkins CI setup (deprecated)](jenkins-access.md)
diff --git a/docs/code-reviews.md b/docs/code-reviews.md
deleted file mode 100644
index dcebf9b..0000000
--- a/docs/code-reviews.md
+++ /dev/null
@@ -1,28 +0,0 @@
-<!--
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
--->
-
-# Code Reviews
-
-We use GitHub pull requests for code reviews.
-1. Commit to a branch on your own fork of the repo that you're changing
-2. Use GitHub to create a pull request
-3. Email out the link to it to dev@cordova.apache.org
-
diff --git a/docs/committer-workflow.md b/docs/committer-workflow.md
deleted file mode 100644
index 3258357..0000000
--- a/docs/committer-workflow.md
+++ /dev/null
@@ -1,187 +0,0 @@
-<!--
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
--->
-
-# Committer Workflow
-
-## One-time Steps
-
-Congratulations! You've gained the confidence of your fellow Cordova committers
-and have been granted the ability to commit code directly, and to apply pull
-requests from others. You should receive an email from our Apache mentor with
-the details of how to setup your account.
-
-## For example workflows of working on iOS or Android platforms & plugins,
-see slides from ApacheCon 2015 talk on [Committer Tools](http://goo.gl/ciGnaR).
-
-### Configure your git repos
-
-It's convenient to have the origin of your git repos to point to Apache's repos
-(as opposed to your clone of them on github). The easiest way to do this is to
-delete them and re-clone them using coho:
-
- git clone https://github.com/apache/cordova-coho.git
- cd cordova-coho
- npm install
- cd ..
- cordova-coho/coho repo-clone -r plugins -r mobile-spec -r ...
-
-Test out your credentials with the following:
-
- git pull
- git push
-
-If all goes well, git push should have asked you for your username and password, and an "Everything up-to-date" message should have been printed.
-
-### Join the private mailing-list
-
-This is a list that only committers can join.
-
-Send an email to `private-subscribe@cordova.apache.org`.
-
-Note that this is a moderated list, so your request to join must be manually accepted.
-
-### Do Your Homework
-
-Understanding how Apache works goes a long way:
-
-* Read through: http://www.apache.org/dev/committers.html
-* Read some board reports: https://www.apache.org/foundation/board/calendar.html
-* Read through some of [Cordova's private mailing-list archives](https://mail-search.apache.org/pmc/private-arch/cordova-private/) (optional)
-
-# Commit Workflow
-
-### Step 1: Mail the Mailing-list (_optional_)
-This is required if any of the following apply:
- * Your change will add/remove/change a public Cordova API.
- * You suspect that your change has a chance of being controversial.
- * You would like feedback before you begin.
-
-When possible, try to phrase things in the form of a proposal. If no one objects (within a workday or two), then consider yourself to have [lazy consensus](http://www.apache.org/foundation/glossary.html#LazyConsensus).
-
-### Step 2: Ensure there is a JIRA issue
- * They are not necessary for *all* changes, (e.g. style nits, refactoring).
- * They should always be used for new features and bugs.
-
-### Step 3: Create a topic branch (_optional_)
- * Using a public topic branch is necessary only when you would like to collaborate on the feature.
- * For small changes, private topic branches are preferred.
- * Note: You should never rebase a public topic branch!
-
-### Step 4: Make your changes
- * Thank you for making the world a better place.
- * Please begin your commit with the issue. Ex. `CB-XXXX **PLATFORM** Fixed broken scrolling`
-
-### Step 5: Test your changes ###
- * You are responsible for testing the commits you push.
- * Tests vary by repo, but in general:
- * Plugins: Automated tests in mobile-spec and/or manual tests in mobile spec.
- * Tools: run `npm test` from the project root.
- * Platforms: Native unit tests (i.e., `cordova-android/test`, `cordova-ios/CordovaLibTests`).
- * Cordova JS: Run `grunt test`.
- * If there is no existing test that exercises your code, consider adding one.
- * If you are writing documentation (i.e., cordova-docs), be aware of the [style guidelines](https://github.com/apache/cordova-docs/blob/master/STYLESHEET.md).
-
-### Step 6: Ask for a code review (_optional_)
- * Do this if you want a second pair of eyes to look at your code before it goes in.
- * Use GitHub pull request.
-
-### Step 7: Push your change
- * When possible, rebase & squash your commits.
- * Make sure you can figure out what your commit does by the first line of your commit description.
- * If it fixes a regression, then also cherry-pick it into the appropriate release branch.
-
-Here is an example workflow for committing a change when you've made it on a topic branch
-
- git pull
- git checkout topic_branch
- git rebase master -i
- git checkout master
- git merge --ff-only topic_branch
- git push
- git branch -d topic_branch
-
-Here is an example workflow for committing a change when you've made it on master:
-
- git pull --rebase
- git rebase origin/master -i # Squash & reword commit messages
- git push
-
-If you ever end up with a merge commit on master that you don't want:
-
- git rebase origin/master
-
-If you need to add your change to a release branch:
-
- git checkout 2.9.x
- git cherry-pick -x COMMIT_HASH # the -x flag adds "cherry-picked from <commit>" to the commit messages
- git push origin 2.9.x
-
-The `git rebase -i` step is your chance to clean up the commit messages and to combine small commits when appropriate. For example:
-
- Commit A: CB-1234 Implemented RockOn feature
- Commit B: CB-1234 Added tests for RockOn
- Commit C: Fixed RockOn not working with empty strings
- Commit D: Renamed RockOn to JustRock
- Commit E: Refactor MainFeature to make use of JustRock.
-
- * In this case, it would be appropriate to combine commits A-D into a single commit, or at least commits A & C.
- * Fewer commits are better because:
- * Easier to comprehend the diff
- * Makes changelog more concise
- * Easier to roll-back commits should the need arise
- * __NEVER REBASE A COMMIT THAT HAS BEEN PUSHED__
- * For all commits:
- * Prefix with JIRA IDs: CB-1234
- * For commits to cordova-js or to plugins:
- * Prefix the message with the affected_platform so that it's clear who should take interest in the commit.
- * e.g.: `CB-1234 android: Improved exec bridge by using strings instead of JSON`
- * e.g.: `CB-1234 all: Fixed plugin loading paths that start with /`
-
-### Step 8: Update JIRA
- * An Apache bot should have already added a comment to the issue with your commit ID (based on the CB-1234 being in the commit message).
- * Click the "Resolve Issue" button.
- * Add a comment saying what version the commit is in (e.g. Fixed in 0.1.3-dev).
-
-### Step 9: Delete your topic branch
-
-If you created a topic branch above, and you've merged your work to master,
-delete your topic branch. This is because we don't want to accumulate a bunch
-of topic branches which don't have anything that hasn't already been merged
-to master.
-
-If your topic branch doesn't get merged to master and sits around for a long
-time to the point of becoming stale or abandoned, also please consider
-deleting those topic branches. No sense in letting cruft accumulate.
-
-# Which Branch to Commit To
-
-### Platforms, mobile-spec, cordova-js, cordova-docs:
- * Commit all changes to branch: `master`.
- * If it fixes a regression, cherry-pick into the release branch (see CuttingReleases).
- * e.g. To cherry pick the last commit from master: `git cherry-pick -x master`.
-
-### All other Repos:
- * Commit all changes to branch: `master`.
-
-# Processing Pull Requests #
-
-See [processing-pull-requests.md](processing-pull-requests.md)
-
diff --git a/docs/jira-triage.md b/docs/jira-triage.md
deleted file mode 100644
index 7c2eb90..0000000
--- a/docs/jira-triage.md
+++ /dev/null
@@ -1,74 +0,0 @@
-<!--
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
--->
-
-# JIRA Issue Triage Process
-
-## Goal
-Every issue needs to be triaged. A triaged issue is actionable and there is an eventual desire to resolve it and has all the fields set accurately. In particular, low quality issues are eliminated from the system. Also, critical issues need to be fixed asap and this process should highlight those issues.
-
-## Process
-Go through each [unresolved bug that is not labeled 'triaged' ordered by created Date](https://issues.apache.org/jira/issues/?jql=status%20not%20in%20(Resolved%2C%20Closed)%20AND%20(labels%20is%20EMPTY%20OR%20labels%20!%3D%20triaged)%20AND%20%20project%20%3D%20CB%20ORDER%20BY%20createdDate%20DESC).
-
-- Ensure the bug details have sufficient details for a reproduction. If not, message the reporter with questions. If the reporter does not respond in 4 business days, resolve the bug as `Invalid`. They are welcome to re-activate the bug with details at a later date.
-- If you can reproduce the issue, add a label `reproduced`. If not, resolve the bug as `Cannot reproduce`.
-- If you are not an expert in the area or do not have the hardware for triaging, reference the platform and/or component owner in helping triage the bug.
-- Edit the following fields:
- - **Component**: Should be ideally a single component. *For plugin issues do not add platform names here.*
- - **Work item type**: Ensure it has the correct classification - feature request vs task vs bug.
- - **Priority**:
- - `Blocker`: This will block the current release of the component. The failure is catastrophic and easy to hit. 'Hello world' and [mobilespec](https://github.com/apache/cordova-mobile-spec) does not build or crashes.
- - `Critical`: This will cause the main function of the component to fail and needs to be fixed asap, but will not block the release.
- - `Major`: Important one to fix.
- - `Minor`, `Trivial`: Nice to haves.
- - **Label**: Use the following:
- - `regression` - A change introduced in previous release or commit that surfaced the issue. Ideally, add a link to the commit that caused the issue.
- - `ios`, `android`, `windows`, `browser`, `node` etc. platforms - You can use these labels, if it is a plugin issue and affects one of these platforms
- - `beginner` or `easyfix` - For issues that are easy for a new contributor to fix. We will eventually publish an easyfix query for new contributors to participate.
- - `triaged` - Indicates bug that has been triaged and does not need to be triaged again.
- - `reproduced` - Bug that has a reproduction.
- - `security`, `bug` - Issues that make the product feel broken. These are usually high priority.
- - `legal` - Reorganizing folder structure, and other necessary (but less impactful) tasks.
- - `dev`, `staging`, `production` - Used to describe the environment.
- - `enhancement`, `optimization` - Used to describe improvements.
- - `feature` - Indicates a new addition.
- - `discussion`, `question`, `rfc` - Requires further conversation or feedback.
- - `in progress` - A state label notifying that there is activity.
- - `invalid`, `won't fix`, `duplicate`, `on hold` - No action needed or possible.
-
- - **Environment**: Represents the machine setup required to reproduce the problem. Great place for mobile OS, host OS versions etc.
- - **Affected version**: Specify the version of the component that the issue appears in.
- - **Assigned To**: If you plan to work on a particular issue, assign it to yourself. If the issue has not been worked on by the assignee i.e. status is not `in progress` or it's clear that the assignee is not looking at this actively, the issue can be taken up by anyone.
-
-At the end of triage session, send an e-mail to the dev list discussing bugs that need urgent attention. Good bugs in this area are recent regressions or other issues having a wide impact. These would require a patch release to fix them.
-
-## Asking for help
-Sometimes there is a bug or a feature request that seems valid, but it might not be high priority for one of the committers to fix. Following up with the issue reporter quickly and coaching them through making a contribution with a pull request is a good idea.
-
-## Tips when asking for more info from reporter
-- If the cordova version is not provided, ask reporter to use “cordova -v” to verify which version of cordova they are using.
-- If the platform version is not provided, ask the reporter to use “cordova platform ls” to verify which platform version he/she is using.
-- If the issue is unclear, ask the reporter to provide more details via screen shot, sample code, or a command line log.
-
-## Dealing with feature requests
-New features to plugins should ideally be cross platform (at least across more than one major platform - Android, iOS, Windows). The design should account for ease of detection or meaningful degradation in the absence of the feature on a particular platform. For feature requests that are overly specific to a particular use-case - we should resolve them with resolution reason `Later` or `Won't Fix`. There is little value in carrying the debt of these issues.
-
-## Open issues
-- Assignments: Who does JIRA triage? Do we need a weekly rotation duty? Should we publish a schedule? Should we distribute by component?
diff --git a/docs/processing-pull-requests.md b/docs/processing-pull-requests.md
deleted file mode 100644
index 31703d4..0000000
--- a/docs/processing-pull-requests.md
+++ /dev/null
@@ -1,133 +0,0 @@
-<!--
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
--->
-
-# Processing Pull Requests
-
-For a visual walkthrough, see slides from ApacheCon 2015 talk on [Committer Tools](http://goo.gl/ciGnaR).
-
-## Prerequisites:
- * Ensure you are familiar with [committer-workflow.md](committer-workflow.md)
-
-## Step 0:
-Find what requests need attention by looking at the GitHub page.
-
-To look at them in aggregate:
-
- coho list-pulls | tee pulls.list | less -R
-
-Alternatively, you can navigate to http://s.apache.org/cordovaPulls to see all PRs for Cordova repos.
-
-To filter out those that you last commented on:
-
- coho list-pulls --hide-user=agrieve
-
-To show only certain repos:
-
- coho list-pulls -r js -r android -r plugin-inappbrowser
-
-### Stale Pull Requests
-
-To close a pull request that is no longer relevant / active:
-
- * Create an empty commit in the repo of the pull request via:
- * `git commit --allow-empty -m "Closing stale pull request: close #99"
-
-## Step 1: Review the change
- * Ensure that we actually want the change (if unsure, bring it up on the ML)
- * If there is no JIRA issue for the change, create one
- * Ensure the JIRA issue has a link to the pull request
- * Ensure the pull request has a link to the JIRA issue
- * View the PR and user's branch in GitHub and request changes be made (if applicable) by adding comments in the web interface
-
-## Step 2: Ensure they have signed the Contributor Agreement
- * For trivial changes, this is not necessary (e.g. use your judgement - e.g. less than 100 lines of code)
- * Find their name on: http://home.apache.org/unlistedclas.html
- * If it is not there, respond with:
-
-_Thanks for the pull request. I've had a look at it and think it looks good. Before we can merge it though, you need to sign Apache's Contributor License Agreement (can be done online): http://www.apache.org/licenses/#clas_
-
-## Step 3: Testing
- * You are responsible for testing the changes that push.
- * Refer to [committer-workflow.md](committer-workflow.md) for how to test each repo.
- * If it would be appropriate to write a test
- * Either write one yourself, or ask the author to do so.
- * If you write one yourself, commit it in a follow-up (don't squash it with theirs)
-
-## Step 4: Merge the change
-
-There are two ways to merge a PR.
-
-The goal is to have one or more commits in `master` that are connected to both the original author and you as the commiter, and include the JIRA issue number in the form CB-#### (no "[]"'s, no ":").
-
-Example commit message:
-
- CB-6124 Make `cordova plugin remove` resilient to a missing plugin directory
-
- This breaks a couple prepare tests that Andrew deletes in the next commit.
-
- github: close #57
-
-### Step 4a: Merge using GitHub UI
-GitHub offers a simple way to [merge PRs using its UI](https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github). "Squash and merge" will squash all commits together, "Merge pull request" create one merge request of the changes. Both will let you set or edit the commit message. If the original author already did a great job with commits and its commit messages, you also can "Rebase and merge" the PR directly onto `master`.
-
-### Step 4b: Merge using `coho`
-Run the following as an exemplary way to merge to master:
-
- coho merge-pr --pr <pr#>
-
-This command will do the following:
-* Update your local master.
-* Fetch the PR and create a branch named `pr/pr#`
-* Attempt a `--ff-only` merge to master. If this fails, then:
- * Perform a rebase of the `pr/pr#` branch.
- * Attempt a `--ff-only` merge to master.
- * On success, it will modify the last commit's message to include. 'This closes #pr' to ensure the corresponding PR closes on pushing to remote.
-
-You then should:
- * Squash as many commits as is reasonable together.
- * In the final commit message (if there are multiple), [tell GitHub to close the pull request](https://help.github.com/articles/closing-issues-via-commit-messages)
-
-#### Step 4b1: Check the author
-Git keeps track of the author of commits separately from the committer of the commit.
-
-Typically, both of these values are set to the person submitting the pull request.
-After your pull/merge/rebase/whatever work, you may find the values have changed - or not.
-What we would typically be looking for is the final commit to have YOU as the committer and the original author as the author.
-
-You can check these fields with the following command:
-
- git log --pretty=full
-
-If the author is set to YOU, and you'd like to reset it to the original author, you can amend the commit:
-
- git commit --amend --author=some_author_id_here
-
-#### Step 4b2: Push the change
-
- git push
-
-## Step 5: Update JIRA
- * Same as you would as if you authored the change.
-
-## Step 6: Final details
- * The commit will get attached to the pull request automatically from the "closes #" in the commit message.
- * If you haven't done so already, thank them for their contribution via a pull request comment :).
-
diff --git a/docs/storing-repo-versions-design.md b/docs/storing-repo-versions-design.md
deleted file mode 100644
index 767b07b..0000000
--- a/docs/storing-repo-versions-design.md
+++ /dev/null
@@ -1,116 +0,0 @@
-<!--
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
--->
-
-# Storing Versions
-This section describes how we _store_ version numbers on our various repositories.
-
-## Cordova Platform Repositories
-There are two aspects of this:
- 1. Storing the version for the repository
- 2. Storing the version of the platform of a created project (as created by the `bin/create` script)
-
-For #1:
- * We will continue to use a `VERSION` file at the root of the repository.
-
-For #2:
- * There is already a way to report the version - through the `cordova/version` script of a created project.
- * The logic of this script used to be different across platforms
- * The new logic here is to have it echo a hard-coded string, which is the contents of the `VERSION` file at the time of creation.
-
-## Cordova JS
-There are two aspects of this:
- 1. Storing the version for the repository
- 2. Storing the version for within generated cordova.js files.
-
-For #1:
- * We will continue to use a `VERSION` file at the root of the repository.
-
-For #2:
- 1. Use build-time logic to stamp cordova.js files with a version through a variable at the top of the file.
- 2. When built in the context of a git repo, and not at a tagged commit, append the git hash.
- 3. When not in a git repo or at a tagged commit, don't try and append a hash.
-
-## Cordova Plugins
-Plugins store their version within their plugin.xml file. No `VERSION` files exist.
-
-## Plugman & CLI
-These tools are built as npm modules, and so use package.json. No `VERSION` files exist.
-
-
-# Choosing Version Numbers Based on Dev vs Release
-This section describes how we __choose version numbers for each branch within our various repositories.
-
-## Cordova Platform Repositories
-The version number should correspond closely to the git branch. When a release branch is made, both the branch and the master branch should be updated. The master branch should **always** have a version number ending in "-dev", which indicates the version currently being developed. A fresh release branch should change the version to an "-rc1" version, and then change to the unqualified version number when it is released.
-
-(This constant version number can be updated manually, but *should* eventually be updated via coho as release branches are made.)
-
-This should give a rough idea how the version number should advance:
-
- 3.3.0-dev
- 3.2.0-dev|
- | |
- --A---B---C---D (master)
- \
- \--E---F---G---H (3.2.x)
- | | |
- 3.2.0-rc1| 3.2.1-rc1
- 3.2.0
-
- * A: This is on the master branch, after 3.1.x has been branched, as 3.2 is being developed.
- * B: This is the branch point for 3.2.x
- * C: The first commit after 3.2.x is branched should identify the master branch as 3.3 is being developed on master now.
- * E: The first commit on the 3.2.x branch should identify the branch as 3.2.0-rc1
- * G: At some point, 3.2.0 is released, and should be identified as such
- * H: After 3.2.0 is released, any further development can be called 3.2.1-rc1
-
-Current support:
-
- ||'''Platform'''||'''Support'''||
- ||Android || {*} ||
- ||BB10 || {o} ||
- ||iOS || {o} ||
- ||OSX || {o} ||
- ||QT || {o} ||
- ||Tizen || {o} ||
- ||WebOS || {o} ||
- ||Win || {o} ||
- ||WP7 || {o} ||
- ||WP8 || {o} ||
- ||www || {o} ||
-
-## Cordova JS
-cordova-js follows the same scheme as platforms.
-
-
-## Cordova Plugins
-Current state is that we have master & dev branches. This is because plugman pulls from master by default, so it must remain stable.
-
- 1. Versions should stay be suffixed with "-dev" on the dev branch.
- 2. This means a releases involves:
- 1. Update plugin.xml's version to "3.1.0" on dev branch
- 2. Merge dev -> master
- 3. Update plugin.xml's version to "3.2.0-dev" on dev branch
-
-## Plugman & CLI
-cordova-plugman and cordova-cli follow the same scheme as platforms.
-
-
diff --git a/docs/versioning-and-release-strategy.md b/docs/versioning-and-release-strategy.md
deleted file mode 100644
index ae21d97..0000000
--- a/docs/versioning-and-release-strategy.md
+++ /dev/null
@@ -1,200 +0,0 @@
-<!--
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
--->
-
-# Versioning Strategy
-
-## Version Format
-
-`SemVer` ([Semantic Versioning](http://www.semver.org)) will be used as the
-version format for all components, including platforms, plugman, CLI, and core
-plugins. The semantics of `SemVer` should be followed, bumping the appropriate digit
-based on the impact of the new content: `MAJOR.MINOR.PATCH`
-
-## Branching and Tagging
-
-All components also follow the same branching and tagging strategy, including
-plugins and tools. A `major.minor.X` release branch (i.e., "3.7.x") should be
-created, and any fixes should be appended to that release branch. New content
-should be on the master branch, and a new release branch created at release
-time. When a release is performed, a release tag is added to the appropriate
-branch (i.e., "3.8.0" tag is put on the "3.8.x" branch).
-
-## Version Behavior
-
-### Plugin Version Behavior
-
-Plugin versions will all be separate and independent. So there may be a "1.2.0"
-of the Device plugin, and a "3.4.5" of the Camera plugin at the same time.
-The bumping of the version numbers of each plugin should be appropriate to the
-new content added to that plugin.
-
-The `cordova plugin add` command will add
-the most recent compatible version of that plugin by default. Alternately the user
-may manually specify an explicit version of that plugin to be installed (i.e.,
-`cordova plugin add org.apache.cordova.device@1.2.0`).
-
-Plugin docs should be
-stored in each plugin repo, so that the docs are versioned with their source
-code.
-
-### Platform Version Behavior
-
-Platform versions will all be separate and independent. So there may be a
-"3.7.0" of the iOS platform and a "4.0.0" of the Android platform at the same
-time. The bumping of version numbers of each platform should be appropriate
-to the new content being added to that platform.
-
-The `cordova platform add`
-command will add a platform version specific to the CLI by default.
-Alternatively, the user may manually specify an explicit version of that
-platform to be installed (i.e., `cordova platform add android@4.0.1`).
-The CLI will hold the list of default versions for each platform
-(i.e., platform version pinning).
-
-Platform docs should be stored in each
-platform repo, so that the docs are versioned with their source code.
-
-Platforms will have an <engine> tag or equivalent, to specify when a
-platform requires a newer version of the CLI.
-
-### `cordova-js` Version Behavior
-
-`cordova-js` versions should continue to be single-sourced, meaning that when
-`cordova-js` is used by multiple components such as `cordova-lib` or
-`cordova-android`, the `cordova-js` version number should not be manually
-modified upon insertion to the consuming component, but instead should retain
-its build-time value. This means that there may be different versions of
-`cordova-js` in use across Cordova components.
-
-### Tools Version Behavior
-
-`cordova-lib`, `plugman`, and CLI versions will all be separate. So there
-may be a "0.25.3" version of `plugman` and a "1.3.2" version of `cordova-lib`
-and a "3.8.0" version of the CLI at the same time. The bumping of version
-numbers of each of the tool components should be appropriate to the new
-content being added to that individual component.
-
-One exception to this
-is that when a new platform is released, and if the only update in the CLI
-is the platform pin, then the CLI receives a bump to its third digit, no
-matter the size of the version bump to those platform(s). If the CLI requires
-a change beyond updating the pin to handle the new platform, or if the CLI
-has other changes, then the `SemVer` semantics still apply for the CLI -
-the second or even first digit of the CLI version may get bumped.
-
-Furthermore,
-if `cordova-lib` or `plugman` have a version bump due to new content (beyond
-updating the pin), then at least the same digit of the CLI version should get
-bumped, since the CLI is primarily composed of `cordova-lib` and `plugman`.
-
-Tools docs should be stored in each
-tool repo, so that the docs are versioned with their source code.
-
-The CLI version number will be the "name" of the Cordova version. Thus
-tools and platform updates will cause a bump of the "Cordova version",
-but plugins will not.
-
-### Pinning
-
-Where Cordova components have dependencies upon other Cordova components
-(i.e., CLI depends on `cordova-lib`) or upon third-party components (i.e.,
-CLI depends on `nopt`), the `package.json` should fully pin the version of
-the dependent component (i.e., "nopt": "2.3.4") (dependency pinning).
-This is in lieu of npm-shrinkwrap since npm-shrinkwrap is not reasonably mature.
-
-### Installing specific versions
-
-For users that want to install a "fixed recipe" of specific versions
-of all the Cordova components, there is one way to do that:
-
-- using specific version numbers:
-
- npm install -g cordova@3.8.0
- cordova platform add android@4.0.1
- cordova plugin add cordova-plugin-device@1.2.3
-
-Do note that third-party dependencies which themselves have dependencies on
-other third-party content (i.e., `nopt` depends on `abbrev`), those relationships
-may not be fully pinned since we don't have control of those third-party
-contents. For example, `nopt` 2.2.1 may specify a non-pinned dependency on version 1.x.x of
-`abbrev`. So a user may get different versions of `abbrev` at different times
-even though they consistently executed `npm install cordova@3.8.0`. As
-npm-shrinkwrap matures, we hope that it will take care of dependency pinning
-across the whole tree. Until then, only part of the tree is properly pinned.
-
-## Upgrade Behavior
-
-When a user updates the version of the CLI they have installed, this CLI
-update has no effect on the platform and plugin versions that are already
-installed in their project, but they may receive a warning or notice if
-the installed platform versions are older than the versions pinned by
-the CLI.
-
-Release notes should be easy for users to find and understand. This is important
-because of the non-trivial number of components.
-
-
-## Release Strategies
-
-1. __On-Demand Releases__
- - Any repository can do an on-demand release at any time.
- - These releases contain critical bug fixes that can't wait for the next scheduled release.
-2. __Weekly Releases__
- - These occur at most once a week (if there are no commits worth releasing, then skip the release).
- - Rationale: Reduces the number of releases to at most one per week so that users are not annoyed by having to update too frequently.
- - Rationale: Reduces the number of blog posts and release notes to write.
- These releases apply to: `CLI`, `Plugman`, and `Core Plugins`.
- - These releases contain non-critical bug fixes as well as new features.
- - Releases generally happen on Thursdays, but can be done on any day so long as it's been a week since the previous release.
-3. __Platform Releases__
- - Release whenever platform maintainers decide they want to release.
- - Tools also get updated with a platform release.
-
-When a component is released, it is tested against the most recent released
-version of its peer components. Note that this is the only combination that is
-tested by the community. For example, when a new Android platform is
-released, it was tested against the latest released tools and plugins. Another
-example, when a plugin is released, it is tested against the latest released
-platforms and tools.
-
-Users are encouraged to use versions that are "date clustered". The reason for
-this is the testing described in the previous paragraph. Attempting to use a
-component that is an outlier in age compared to the other components may yield
-unpredictable behavior, since that combination may not have been tested by
-the community.
-
-In general, there are no support streams for Cordova components. If there is
-a defect to be fixed or a new feature to be added, it will be done in the master
-(trunk) stream only, and made available in the next release. Fixes are not
-backported to already-released branches. There may be exceptions to this, such
-as an important security vulnerability, but these exceptions are rare.
-
-For the reason in the previous paragraph, users are encouraged to use recent
-versions of Cordova components, and to stay reasonably current with new versions
-of Cordova components. This becomes important not just for bug fixes,
-but also for any enablement of new versions of device operating systems (i.e.,
-iOS 8, Android L, etc). This enablement is not backported to older versions.
-
-Related docs:
-* [storing-repo-versions-design.md](storing-repo-versions-design.md)
-* [cadence-release-process.md](cadence-release-process.md)
-* [committer-workflow.md](committer-workflow.md)
-
