{"action":"created","issue":{"url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4016","repository_url":"https://api.github.com/repos/ReactiveX/RxJava","labels_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4016/labels{/name}","comments_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4016/comments","events_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4016/events","html_url":"https://github.com/ReactiveX/RxJava/issues/4016","id":160867046,"number":4016,"title":"Policies and going forward with RxJava versions","user":{"login":"akarnokd","id":1269832,"avatar_url":"https://avatars.githubusercontent.com/u/1269832?v=3","gravatar_id":"","url":"https://api.github.com/users/akarnokd","html_url":"https://github.com/akarnokd","followers_url":"https://api.github.com/users/akarnokd/followers","following_url":"https://api.github.com/users/akarnokd/following{/other_user}","gists_url":"https://api.github.com/users/akarnokd/gists{/gist_id}","starred_url":"https://api.github.com/users/akarnokd/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/akarnokd/subscriptions","organizations_url":"https://api.github.com/users/akarnokd/orgs","repos_url":"https://api.github.com/users/akarnokd/repos","events_url":"https://api.github.com/users/akarnokd/events{/privacy}","received_events_url":"https://api.github.com/users/akarnokd/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ReactiveX/RxJava/labels/Discussion","name":"Discussion","color":"5319e7"},{"url":"https://api.github.com/repos/ReactiveX/RxJava/labels/Information","name":"Information","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-06-17T11:22:41Z","updated_at":"2016-06-17T17:57:19Z","closed_at":null,"body":"As a newly named lead contributor, I suggest the following policies and future plans regarding RxJava.\r\n\r\n# RxJava 1.x\r\n\r\nThe unfortunate side-effect of Ben leaving was the slowing down of managing PRs and releases. I intend to speed this up again with the following policies:\r\n\r\n## Trivial PRs\r\n\r\nTrivial PRs no longer require at least 2 :+1: from contributors and can be merged by any of them on their own right. A PR is trivial if it is about *typo fixes in the javadocs*, *test fixes* or *performance tests*.\r\n\r\nSince documentation expressiveness is a common place for lengthy arguments, the **merge first, discuss later** policy should be in effect; disagreeing parties are welcome to post their follow-up PRs.\r\n\r\n## Bugfixes\r\n\r\nIf a PR aims to fix a bug without changing the public surface API, collaborators can merge them on their own right or ask for additional review from the other collaborators. In this latter case, an additional :+1: is required for merging.\r\n\r\nIf the bugfix involves surface API changes, at least 2 :+1:'s are required. If the proposer of a PR is a collaborators, that automatically counts as :+1:\r\n\r\nIf the bug (of any complexity) is related to other platforms, such as Android, or is a cross-library bug, such as with rxjava-string, and the fix itself is of some doubt, I propose accepting @JakeWharton's, @artem-zinnatullin's and @davidmoten's  :+1: as equal to the :+1:'s of the core collaborators.\r\n\r\nWhen a bug has been identified and the fix proposed, a patch release has to follow within a week for high impact bugs or within 2 weeks for medium impact bugs. For low impact bugs, the regular release cycle applies (see below). (Example high impact bug: crash in `flatMap`; medium impact bug: performance degradation in `ReplaySubject`; low impact bug: missing argument validation.)\r\n\r\nIf the proposed bug is not merged within the time limit due to lack of feedback or lengthy discussions, I reserve the right to be the final judge on the issue.\r\n\r\n## Performance enhancements\r\n\r\nIf a PR contains performance enhancements and no surface API changes, collaborators are allowed to merge the PR without the need for additional :+1: provided there is at least one other person (collaborator, the poster of the original issue or other contributors) confirming the improvements.\r\n\r\n## API enhancements\r\n\r\nThere are usually 2 complaints with RxJava's API: \"it has too many methods/operators but doesn't have my operator\". \r\n\r\nOn one hand, I'd like to avoid RxJava becoming a dumping ground for all sorts of exotic yet small impact operators. The existing extension points `lift`, `compose` and `extend` allow adding operators with minimal inconveniences.\r\n\r\nOn the other hand, past enhancement PRs were delayed quite significantly, due to lack of attention or too long discussions, hindering progress on releases and other PRs.\r\n\r\nTo avoid these problems, enhancement PRs require at least 2 :+1: from the collaborators. If the proposer is also a collaborator, the PR **still requires at least 2 :+1: from the other collaborators**.\r\n\r\nIf such a PR doesn't get the required :+1: (and thus merged) within two consecutive releases, the PR can be closed by any collaborator.\r\n\r\n## Issues\r\n\r\nIssues identified as questions or discussions can be closed by collaborators after 30 calendar days of inactivity. Inactivity means the question appears to be answered or the OP didn't provide additional feedback.\r\n\r\nBug reports should be closed if the fix PR has been merged or rejected without any alternative fix.\r\n\r\nIssues related to test failures on Travis CI should be closed if the failure doesn't appear within 60 calendar days again in PRs or in master builds.\r\n\r\nIssues related to feature requests or enhancement proposals can be closed after 30 calendar days and if two or more :-1: has been signalled.\r\n\r\n## Patch releases\r\n\r\nAs features and bugfixes are merged in and no medium or high impact bugfix is among them, a patch release happen at most within 4 weeks. In the unlikely event there are no merges within this time period, the at most 4 week countdown starts when the next PR is merged. \r\n\r\nMedium or high impact bugs and enhancements can be released sooner, provided at least 2 :+1: is received for a release proposal.\r\n\r\nSince a release involves updating the `CHANGES.md`, :+1: on the related issue and PRs all count towards the minimum 2. (I.e., no need to :+1: both the issue and the PR actually changing the file).\r\n\r\n## Release 1.2\r\n\r\nThe 1.1.x has accumulated quite a few deprecated APIs and I think most high and medium bugs (mostly backpressure related) have been ironed out. \r\n\r\nFollowing the 1.0.x -> 1.1.0 switch before, I propose finishing up and releasing **1.1.7** in 4 weeks from now (**15/7/2016**) and then release **1.2** in 5 weeks from now (**22/7/2016**). Version 1.1.7 will have the API intact. Version 1.2 will have the deprecated API removed and beta/experimental APIs promoted/demoted. Suggestions for further deprecation should go through a regular PR before that.\r\n\r\nI'll distribute a questionnaire regarding the API promotion/demotion to the collaborators and also publish it publicly. \r\n\r\n# RxJava 2.x\r\n\r\nAlthough there is a working RxJava 2.x branch, its architecture is quite outdated. \r\n\r\nThe new architecture, as described in [Design.md](https://github.com/ReactiveX/RxJava/blob/2.x/DESIGN.md) focuses on performance and reduction of object allocations whenever possible. \r\n\r\nSwitching to this new architecture requires changing how operators are instantiated in the first place. This change has the largest one-time impact for 2.x. Once done, applying the advanced operator-fusion to the operators can be done in smaller PRs thereafter. \r\n\r\nAdding operator-fusion won't block release candidates and can happen incrementally.\r\n\r\nThis is my proposed schedule for 2.0:\r\n\r\n  - Update core architecture: till: **1/7/2016**\r\n  - Agree on the maven group ID (#3170): till **15/7/2016**\r\n  - Decide about operators: to drop, to port from 1.x or to change behavior: till: **5/8/2016**\r\n  - Add missing javadoc: till **12/8/2016**\r\n  - Synchronize unit tests from 1.x: till **19/08/2016**\r\n  - Release Candidate 1 : **26/08/2016**\r\n  - Release Candidate 2 : **23/09/2016**\r\n  - Release Candidate 3 : **21/10/2016**\r\n  - Release 2.0: **28/10/2016**\r\n\r\n# Other responsibilities of mine\r\n\r\nYou may know I have been contributing to Project Reactor lately and also doing my research in the Reactive-Streams-Commons (Rsc) project. Since both Project Reactor and RxJava 2.x benefit from Rsc (and are basically cousins in their style anyway), I don't expect any duplicate work or split attention between these projects.\r\n\r\nIn addition, I don't consider Project Reactor to be a direct competition because its dependency on Java 8 and the choice of supported operators (some missing, others extra).\r\n\r\nLastly, I'm also working under their umbrella on porting Rsc/Reactor to JavaScript/TypeScript and .NET. These ports happen mainly for the reason that neither RxJS 5 nor Rx.NET 3 seems to care about the advancements made in RxJava (and in Rsc): synchronous cancellation, backpressure or the Reactive-Streams design in general (not to mention, operator-fusion). (As a side-effect, implementing operators in .NET already revealed a few concurrency-related bugs in the Java implementation.)\r\n\r\nAlthough tedious at times, I don't expect any interference on this regard and can focus on leading RxJava."},"comment":{"url":"https://api.github.com/repos/ReactiveX/RxJava/issues/comments/226837945","html_url":"https://github.com/ReactiveX/RxJava/issues/4016#issuecomment-226837945","issue_url":"https://api.github.com/repos/ReactiveX/RxJava/issues/4016","id":226837945,"user":{"login":"JakeWharton","id":66577,"avatar_url":"https://avatars.githubusercontent.com/u/66577?v=3","gravatar_id":"","url":"https://api.github.com/users/JakeWharton","html_url":"https://github.com/JakeWharton","followers_url":"https://api.github.com/users/JakeWharton/followers","following_url":"https://api.github.com/users/JakeWharton/following{/other_user}","gists_url":"https://api.github.com/users/JakeWharton/gists{/gist_id}","starred_url":"https://api.github.com/users/JakeWharton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JakeWharton/subscriptions","organizations_url":"https://api.github.com/users/JakeWharton/orgs","repos_url":"https://api.github.com/users/JakeWharton/repos","events_url":"https://api.github.com/users/JakeWharton/events{/privacy}","received_events_url":"https://api.github.com/users/JakeWharton/received_events","type":"User","site_admin":false},"created_at":"2016-06-17T17:57:19Z","updated_at":"2016-06-17T17:57:19Z","body":"Thanks for the clarification. :+1:\n\nOn Fri, Jun 17, 2016 at 1:55 PM George Campbell <notifications@github.com>\nwrote:\n\n> @JakeWharton <https://github.com/JakeWharton> yes a few methods where\n> deleted between 1.0 and 1.1. They were:\n>\n>    - rx.Observable.onBackpressureBlock(int maxQueueLength)\n>    - rx.Observable.onBackpressureBlock()\n>    - rx.subjects.AsyncSubject.getValues(T[])\n>    - rx.subjects.PublishSubject.getValue()\n>    - rx.subjects.PublishSubject.getValues()\n>    - rx.subjects.PublishSubject.getValues(T[])\n>    - rx.subjects.PublishSubject.hasValue()\n>    - rx.subjects.SerializedSubject.getThrowable()\n>    - rx.subjects.SerializedSubject.getValue()\n>    - rx.subjects.SerializedSubject.getValues()\n>    - rx.subjects.SerializedSubject.getValues(T[])\n>    - rx.subjects.SerializedSubject.hasCompleted()\n>    - rx.subjects.SerializedSubject.hasThrowable()\n>    - rx.subjects.SerializedSubject.hasValue()\n>    - rx.subjects.Subject.getThrowable()\n>    - rx.subjects.Subject.getValue()\n>    - rx.subjects.Subject.getValues()\n>    - rx.subjects.Subject.getValues(T[])\n>    - rx.subjects.Subject.hasCompleted()\n>    - rx.subjects.Subject.hasThrowable()\n>    - rx.subjects.Subject.hasValue()\n>\n> Only methods marked @Experiment/@Beta <https://github.com/Beta> AND\n> @Depericated are eligible for removal.\n>\n> —\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/ReactiveX/RxJava/issues/4016#issuecomment-226837514>,\n> or mute the thread\n> <https://github.com/notifications/unsubscribe/AAEEERdXvtsHeX6uxvTEIDngLsJB3rUrks5qMt-WgaJpZM4I4RD9>\n> .\n>\n"}}
{"actor":{"display_login":"JakeWharton"}}