.github/ISSUE_TEMPLATE/support-question.md

@@ -1,14 +1,12 @@
 ---
 name: Support Question
-about: 'If you have a question, please check out our StackOverflow! '
+about: "If you have a question, please check out our StackOverflow! "
+---We primarily use GitHub as an issue tracker; for usage and support questions, please check out these resources below. Thanks!
 
 ---
 
-We primarily use GitHub as an issue tracker; for usage and support questions, please check out these resources below. Thanks! 
+- StackOverflow: https://stackoverflow.com/questions/tagged/rxjs using the tag `rxjs`
+- Also have a look at the readme for more information, possibly can have some answers already:
 
----
-* StackOverflow: https://stackoverflow.com/questions/tagged/rxjs using the tag `rxjs`
-* Also have a look at the readme for more information, possibly can have some answers already:
-- https://github.com/ReactiveX/rxjs/blob/master/README.md
-- https://github.com/ReactiveX/rxjs/blob/master/MIGRATION.md
-- https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-operators.md
+* https://github.com/ReactiveX/rxjs/blob/master/README.md
+* https://github.com/ReactiveX/rxjs/blob/master/MIGRATION.md

.github/PULL_REQUEST_TEMPLATE.md

@@ -8,9 +8,8 @@ If your PR is the addition of a new operator, please make sure all these boxes a
 - [ ] If possible, write a `asDiagram` test case too, for PNG diagram generation purposes
 - [ ] The spec file should have a type definition test at the end of the spec to verify type definition for various use cases
 - [ ] The operator must be documented in JSDoc style in the implementation file, including also the PNG marble diagram image
-- [ ] The operator should be listed in `doc/operators.md` in a category of operators
+- [ ] The operator should be listed in `docs_app/content/guide/operators.md` in a category of operators
 - [ ] The operator should also be documented. See [Documentation Guidelines](../CONTRIBUTING.md).
-- [ ] It should also be inserted in the operator decision tree file `doc/decision-tree-widget/tree.yml`
 - [ ] You may need to update `MIGRATION.md` if the operator differs from the corresponding one in RxJS v4
 -->
 

CHANGELOG.md

@@ -1,3 +1,32 @@
+## [6.5.5](https://github.com/reactivex/rxjs/compare/6.5.3...6.5.5) (2020-04-03)
+
+
+### Bug Fixes
+
+* **fetch:** don't leak event listeners added to passed-in signals ([#5305](https://github.com/reactivex/rxjs/issues/5305)) ([06bf3a3](https://github.com/reactivex/rxjs/commit/06bf3a30c65d85f18aeb2ef2b800e918c8d36979))
+* **pipe:** Special handling for 0-arg case. ([#4936](https://github.com/reactivex/rxjs/issues/4936)) ([2e9d867](https://github.com/reactivex/rxjs/commit/2e9d867d8d082dc6130cce3cd49988c4e3c0c424))
+* don't reassign closed-over parameter in fromFetch ([#5234](https://github.com/reactivex/rxjs/issues/5234)) ([0377710](https://github.com/reactivex/rxjs/commit/03777102a3491e0b3dac00c53a1b217c45616fc6)), closes [#5233](https://github.com/reactivex/rxjs/issues/5233) [#5233](https://github.com/reactivex/rxjs/issues/5233)
+* **asapScheduler:** resolved memory leak ([#5183](https://github.com/reactivex/rxjs/issues/5183)) ([4312af5](https://github.com/reactivex/rxjs/commit/4312af5c5c5dde51873a8f02387bea25e23a36ca)), closes [#5016](https://github.com/reactivex/rxjs/issues/5016)
+* chain subscriptions from interop observables for 6.x ([#5178](https://github.com/reactivex/rxjs/issues/5178)) ([cbc7721](https://github.com/reactivex/rxjs/commit/cbc77213e97ecc00d90a65ecf18707b76ebfe7fc))
+* clear subscription on shareReplay completion ([#5044](https://github.com/reactivex/rxjs/issues/5044)) ([9f87505](https://github.com/reactivex/rxjs/commit/9f87505deae0aeae7dd53918e392487d6de7ab73)), closes [#5034](https://github.com/reactivex/rxjs/issues/5034)
+* **fromFetch:** passing already aborted signal to init aborts fetch ([c2657a8](https://github.com/reactivex/rxjs/commit/c2657a868e1c079d50f63ce5c0850572d491238a))
+* missing package.json in rxjs/fetch ([#5001](https://github.com/reactivex/rxjs/issues/5001)) ([06fb735](https://github.com/reactivex/rxjs/commit/06fb73555375095bb55cdd02287bea5f9c0ddafc))
+
+
+
+## [6.5.4](https://github.com/reactivex/rxjs/compare/6.5.3...6.5.4) (2019-12-27)
+
+
+### Bug Fixes
+
+* **asapScheduler:** resolved memory leak ([#5183](https://github.com/reactivex/rxjs/issues/5183)) ([4312af5](https://github.com/reactivex/rxjs/commit/4312af5)), closes [#5016](https://github.com/reactivex/rxjs/issues/5016)
+* chain subscriptions from interop observables for 6.x ([#5178](https://github.com/reactivex/rxjs/issues/5178)) ([cbc7721](https://github.com/reactivex/rxjs/commit/cbc7721))
+* **shareReplay** clear subscription on shareReplay completion ([#5044](https://github.com/reactivex/rxjs/issues/5044)) ([9f87505](https://github.com/reactivex/rxjs/commit/9f87505)), closes [#5034](https://github.com/reactivex/rxjs/issues/5034)
+* **fromFetch:** passing already aborted signal to init aborts fetch ([c2657a8](https://github.com/reactivex/rxjs/commit/c2657a8))
+* missing package.json in rxjs/fetch ([#5001](https://github.com/reactivex/rxjs/issues/5001)) ([06fb735](https://github.com/reactivex/rxjs/commit/06fb735))
+
+
+
 ## [6.5.3](https://github.com/reactivex/rxjs/compare/6.5.2...6.5.3) (2019-09-03)
 
 ### Bug Fixes

CONTRIBUTING.md

@@ -30,6 +30,7 @@ Contents
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
 ---
+
 - Related documents
   - [Creating Operators](doc/operator-creation.md)
   - [Writing Marble Tests](doc/writing-marble-tests.md)
@@ -39,80 +40,82 @@ Contents
 (This document is a work and progress and is subject to change)
 
 ## Submitting a Pull Request (PR)
+
 Before you submit your Pull Request (PR) consider the following guidelines:
 
-* Search [GitHub](https://github.com/ReactiveX/RxJS/pulls) for an open or closed PR
+- Search [GitHub](https://github.com/ReactiveX/RxJS/pulls) for an open or closed PR
   that relates to your submission. You don't want to duplicate effort.
-* Make your changes in a new git branch:
+- Make your changes in a new git branch:
 
-     ```shell
-     git checkout -b my-fix-branch master
-     ```
+  ```shell
+  git checkout -b my-fix-branch master
+  ```
 
-* Create your patch, following [code style guidelines](#coding-style-guidelines), and **including appropriate test cases**.
-* Run the full test suite and ensure that all tests pass.
-* Run the micro and macro performance tests against your feature branch and compare against master
+- Create your patch, following [code style guidelines](#coding-style-guidelines), and **including appropriate test cases**.
+- Run the full test suite and ensure that all tests pass.
+- Run the micro and macro performance tests against your feature branch and compare against master
   to ensure performance wasn't changed for the worse.
-* Commit your changes using a descriptive commit message that follows our
+- Commit your changes using a descriptive commit message that follows our
   [commit message guidelines](#commit-message-guidelines). Adherence to these conventions
   is necessary because release notes are automatically generated from these messages.
 
-     ```shell
-     git commit -a
-     ```
+  ```shell
+  git commit -a
+  ```
+
   Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
 
-* Push your branch to GitHub:
+- Push your branch to GitHub:
 
-    ```shell
-    git push origin my-fix-branch
-    ```
+  ```shell
+  git push origin my-fix-branch
+  ```
+
+- In GitHub, send a pull request to `RxJS:master`.
+- If we suggest changes then:
 
-* In GitHub, send a pull request to `RxJS:master`.
-* If we suggest changes then:
-  * Make the required updates.
-  * Re-run the test suites to ensure tests are still passing.
-  * Re-run performance tests to make sure your changes didn't hurt performance.
-  * Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
+  - Make the required updates.
+  - Re-run the test suites to ensure tests are still passing.
+  - Re-run performance tests to make sure your changes didn't hurt performance.
+  - Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
 
     ```shell
     git rebase master -i
     git push -f
     ```
 
-  * When updating your feature branch with the requested changes, please do not overwrite the commit history, but rather contain the changes in new commits. This is for the sake of a clearer and easier review process.
+  - When updating your feature branch with the requested changes, please do not overwrite the commit history, but rather contain the changes in new commits. This is for the sake of a clearer and easier review process.
 
 That's it! Thank you for your contribution!
 
-
 ### After your pull request is merged
 
 After your pull request is merged, you can safely delete your branch and pull the changes
 from the main (upstream) repository:
 
-* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
+- Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
 
-    ```shell
-    git push origin --delete my-fix-branch
-    ```
+  ```shell
+  git push origin --delete my-fix-branch
+  ```
 
-* Check out the master branch:
+- Check out the master branch:
 
-    ```shell
-    git checkout master -f
-    ```
+  ```shell
+  git checkout master -f
+  ```
 
-* Delete the local branch:
+- Delete the local branch:
 
-    ```shell
-    git branch -D my-fix-branch
-    ```
+  ```shell
+  git branch -D my-fix-branch
+  ```
 
-* Update your master with the latest upstream version:
+- Update your master with the latest upstream version:
 
-    ```shell
-    git pull --ff upstream master
-    ```
+  ```shell
+  git pull --ff upstream master
+  ```
 
 ## Coding Style Guidelines
 
@@ -127,15 +130,14 @@ from the main (upstream) repository:
 - The documentation is auto-generated directly from the source code.
 - In short: From the source code we generate JSON documents, describing each operator, function ... and render this JSON within an Angular application
 - The folder `docs-app` contains everything you need for building and developing the docs
-- the folder `doc` used to be the documentation, but should remain until all content is transferred.
 - The [Documentation README](docs_app/README.md) will support you
 - After a PR is merged to master the docs will be published to https://rxjs.dev/
 
 ## Unit Tests
 
 Unit tests are located under the [spec directory](/spec). Unit tests over synchronous operators and operations
-can be written in a standard [jasmine](http://jasmine.github.io/) style. Unit tests written against any
-asynchronous operator should be written in [Marble Test Style outlined in detail here](doc/writing-marble-tests.md).
+can be written in a standard [chai](https://www.chaijs.com/) style. Unit tests written against any
+asynchronous operator should be written in [Marble Test Style outlined in detail here](doccs_app/content/guide/testing/internal-marble-tests.md).
 
 Each operator under test must be in its own file to cover the following cases:
 
@@ -154,26 +156,26 @@ then it must cover the following cases:
 - If an error is thrown
 
 ### CI Tests
+
 - Using [Travis](https://travis-ci.org/) on your forked version of RxJS will allow running CI tests on that fork before submitting a PR to master
- - Simply create a `Travis` account and add your fork as a new project
+- Simply create a `Travis` account and add your fork as a new project
 - [Sauce Labs](https://saucelabs.com/) setup will allow performing automated browser tests on the fork. Since `saucelabs` doesn't perform browser tests on a PR, this will help verify test results before PR's are checked into master.
- - In your `Travis` repo configuration, set the environment variables SAUCE_USERNAME and SAUCE_ACCESS_KEY to your `saucelabs` account ([reference](https://cloud.githubusercontent.com/assets/1210596/12679038/b9ba4eb6-c656-11e5-8c9b-b063c9a3f9dc.png))
+- In your `Travis` repo configuration, set the environment variables SAUCE_USERNAME and SAUCE_ACCESS_KEY to your `saucelabs` account ([reference](https://cloud.githubusercontent.com/assets/1210596/12679038/b9ba4eb6-c656-11e5-8c9b-b063c9a3f9dc.png))
 - As master runs both of these tests per each check in, it'd be welcome to setup those test before creating your PR
 
 ## Performance Tests
 
 One of the primary goals of this library is (and will continue to be) great performance. As such, we've employed a variety of performance
 testing techniques.
 
-  - DON'T labor over minute variations in ops/sec or milliseconds, there will always be variance in perf test results.
-  - DON'T alter a performance test unless absolutely necessary. Performance tests may be compared to previous results from previous builds.
-  - DO run tests multiple times and make sure the margins of error are low
-  - DO run tests in your feature branches and compare them to master
-  - DO add performance tests for all new operators
-  - DO add performance tests that you feel are missing from other operators
-  - DO add additional performance tests for all worthy code paths. If you develop an operator with special handling for scalar observables,
-    please add tests for those scenarios
-
+- DON'T labor over minute variations in ops/sec or milliseconds, there will always be variance in perf test results.
+- DON'T alter a performance test unless absolutely necessary. Performance tests may be compared to previous results from previous builds.
+- DO run tests multiple times and make sure the margins of error are low
+- DO run tests in your feature branches and compare them to master
+- DO add performance tests for all new operators
+- DO add performance tests that you feel are missing from other operators
+- DO add additional performance tests for all worthy code paths. If you develop an operator with special handling for scalar observables,
+  please add tests for those scenarios
 
 ### Macro
 
@@ -193,7 +195,6 @@ npm run build_all
 protractor protractor.conf.js
 ```
 
-
 ### Micro
 
 [Micro performance tests](perf/micro) really only serve to test operations per second. They're quick and easy to develop, and provide a reasonable look into the
@@ -214,13 +215,14 @@ node perf/micro zip
 
 ## Commit Message Guidelines
 
-We have very precise rules over how our git commit messages can be formatted.  This leads to **more
+We have very precise rules over how our git commit messages can be formatted. This leads to **more
 readable messages** that are easy to follow when looking through the **project history**. But also,
 we use the git commit messages to **generate the RxJS change log**. Helper script `npm run commit`
 provides command line based wizard to format commit message easily.
 
 ### Commit Message Format
-Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
+
+Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
 format that includes a **type**, a **scope** and a **subject**:
 
 ```
@@ -237,38 +239,43 @@ Any line of the commit message cannot be longer than 100 characters! This allows
 to read on GitHub as well as in various git tools.
 
 ### Revert
-If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
+
+If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
 
 ### Type
+
 Must be one of the following:
 
-* **feat**: A new feature
-* **fix**: A bug fix
-* **docs**: Documentation only changes
-* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
+- **feat**: A new feature
+- **fix**: A bug fix
+- **docs**: Documentation only changes
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
   semi-colons, etc)
-* **refactor**: A code change that neither fixes a bug nor adds a feature
-* **perf**: A code change that improves performance
-* **test**: Adding missing tests
-* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
+- **refactor**: A code change that neither fixes a bug nor adds a feature
+- **perf**: A code change that improves performance
+- **test**: Adding missing tests
+- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
   generation
 
 ### Scope
-The scope could be anything specifying place of the commit change. For example
-`Observable`, `Subject`, `switchMap`, etc.
+
+The scope could be anything specifying the place of the commit change. For example `Observable`, `Subject`, `switchMap`, etc.
 
 ### Subject
+
 The subject contains succinct description of the change:
 
-* use the imperative, present tense: "change" not "changed" nor "changes"
-* don't capitalize first letter
-* no dot (.) at the end
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize first letter
+- no dot (.) at the end
 
 ### Body
+
 Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
 The body should include the motivation for the change and contrast this with previous behavior.
 
 ### Footer
+
 The footer should contain any information about **Breaking Changes** and is also the place to
 reference GitHub issues that this commit **Closes**.