Preparation for deletion of develop branch

CONTRIBUTING.md

@@ -4,25 +4,25 @@ There are many ways to contribute to the project, including fixing issues or imp
 
 # Questions
 
-This is the issue tracker for `sl-ember-store`. The community uses this site to collect and track bugs and discussions of
-new features. If you are having difficulties using `sl-ember-store` or have a question about usage please ask a question
-on Stack Overflow: http://stackoverflow.com/questions/ask?tags=sl-ember-store
+This is the issue tracker for `sl-ember-store`. The community uses this site to collect and track bugs and
+discussions of new features. If you are having difficulties using `sl-ember-store` or have a question about usage
+please ask a question on Stack Overflow: http://stackoverflow.com/questions/ask?tags=sl-ember-store
 
 # Issues
 
 Think you've found a bug or have a new feature to suggest? Let us know!
 
 ## Reporting a Bug
 
-1. Make sure you have the latest version of the code, if possible, as we may have already fixed your bug.  This project uses the [git-flow branching model](https://github.com/nvie/gitflow) so the latest changes will be in the `develop` branch.
+1. Make sure you have the latest version of the code, if possible, as we may have already fixed your bug.
 
 2. Search for similar issues. It's possible somebody has encountered this bug already.
 
-3. Provide a demo that specifically shows the problem. This demo should be fully operational with the exception of the
-bug you want to demonstrate. The more pared down, the better. Issues with demos are prioritized.
+3. Provide a demo that specifically shows the problem. This demo should be fully operational with the exception of
+the bug you want to demonstrate. The more pared down, the better. Issues with demos are prioritized.
 
-4. Your issue will be verified. The provided demo will be tested for correctness. The sl-ember-store team will work with
-you until your issue can be verified.
+4. Your issue will be verified. The provided demo will be tested for correctness. The sl-ember-store team will work
+with you until your issue can be verified.
 
 5. Keep up to date with feedback from the sl-ember-store team on your ticket. Your ticket may be closed if it becomes
 stale.
@@ -38,12 +38,12 @@ there is a bug and the faster we'll be able to take action.
 1. Search Issues for similar feature requests. It's possible somebody has already asked
 for this feature or provided a pull request that we're still discussing.
 
-2. Provide a clear and detailed explanation of the feature you want and why it's important to add. Keep in mind that we
-want features that will be useful to the majority of our users and not just a small subset. If you're just targeting a
-minority of users, consider writing your own addon library for `ember-cli` that extends this one.
+2. Provide a clear and detailed explanation of the feature you want and why it's important to add. Keep in mind that
+we want features that will be useful to the majority of our users and not just a small subset. If you're just
+targeting a minority of users, consider writing your own addon library for `ember-cli` that extends this one.
 
-3. If the feature is complex, consider writing some initial documentation for it. If we do end up accepting the feature
-it will need to be documented and this will also help us to understand it better ourselves.
+3. If the feature is complex, consider writing some initial documentation for it. If we do end up accepting the
+feature it will need to be documented and this will also help us to understand it better ourselves.
 
 4. Attempt a Pull Request. If you are willing to help the project out, you can submit a Pull Request. We always have
 more work to do than time to do it. If you can write some code then that will speed the process along.
@@ -74,48 +74,19 @@ functionality or fixing a bug, we need a test!
 5. Commit your changes. If your pull request fixes an issue specify it in the commit message. Here's an example:
 `git commit -m "Close #12 Fix passing of context"`
 
-6. Push to your fork and submit a pull request againt the `develop` branch (due to our use of the [git-flow branching model](https://github.com/nvie/gitflow)). Please provide us with some explanation of why you made the changes you made. For new features make sure to explain a standard use case to us.
+6. Push to your fork and submit a pull request againt the `master` branch. Please provide us with some explanation
+of why you made the changes you made. For new features make sure to explain a standard use case to us.
 
-We try to be quick about responding to tickets but sometimes we get a bit backlogged.  If the response is slow, try to
-find someone on IRC(#softlayer) to give the ticket a review.
+We try to be quick about responding to tickets but sometimes we get a bit backlogged.  If the response is slow, try
+to find someone on IRC(#softlayer) to give the ticket a review.
 
-Some things that will increase the chance that your pull request is accepted, taken straight from the Ruby on Rails
-guide:
+Some things that will increase the chance that your pull request is accepted include:
 
-    * Use Node idioms and helpers.
-    * Include tests that fail without your code, and pass with it.
-    * Update the documentation, the surrounding one, examples elsewhere, guides, whatever is affected by your
-    contribution.
+* Include tests that fail without your code, and pass with it.
+* Update the documentation, the surrounding one, examples elsewhere, guides, whatever is affected by your contribution.
+* Follow the [Ember.js Style Guide](https://github.com/softlayer/ember-style-guide).
 
-#### Syntax ####
-
-    * Four spaces, no tabs.
-    * No trailing whitespace. Blank lines should not have any space.
-    * Follow the conventions you see used in the source already.
-
-#### Inline Documentation Guidelines ####
-
-All inline documentation is written using [JSDoc](http://usejsdoc.org/). Follow these rules when updating or writing
-new documentation:
-
-    1. All code blocks must be fenced.
-    2 All code blocks must be valid code for syntax highlighting.
-    3. All examples in code blocks must be aligned.
-    4. Use two spaces between the code and the example: `foo(); // result`.
-    5. All references to code words must be enclosed in backticks.
-    6. Prefer a single space between sentences.
-    7. Wrap long markdown blocks > 120 characters.
-    8. Don't include blank lines after `@param` definitions.
-
-
-#### Style Conventions ####
-
-* `thisPropertyName`
-* `Global.Class.attribute`
-* `thisFunction()`
-* `Global.CONSTANT_NAME`
-* `true`, `false`, `null`, `undefined` (when referring to programming values)
 
 And in case we didn't emphasize it enough: **we love tests!**
 
-NOTE: Partially copied from https://raw.githubusercontent.com/stefanpenner/ember-cli/master/CONTRIBUTING.md
+NOTE: Partially copied from https://raw.githubusercontent.com/stefanpenner/ember-cli/master/CONTRIBUTING.md

RELEASE-INSTRUCTIONS.md

@@ -2,8 +2,7 @@
 
 This document captures the steps a project maintainer should follow when releasing a new version of this Addon.
 
-* Merge all desired pull requests into `develop` branch
-* Merge `develop` branch into `master` branch
+* Merge all desired pull requests into `master` branch
 * If change is due to upgrading Ember CLI version
     * Update Ember CLI version text in README.md file
 * Update CHANGELOG.md
@@ -23,7 +22,6 @@ This document captures the steps a project maintainer should follow when releasi
     * `git push origin --tags`
     * `npm publish --registry http://registry.npmjs.org/`
         * Note: `--registry` flag is workaround for occasional issues with default SSL url
-* Merge `master` branch into `develop`
 
 If any of these conditions are true: