Policies and going forward with RxJava versions #4016
Comments
|
Very nice to see at last RSC sourcing two flavors, that will translate in a more robust, efficient operator chain. Very happy and proud that we can at last contribute to rxjava indirectly 👍 I can imagine already cross-library fusion that might be therefore discussed in Reactive Streams. We indeed use Java 8 and only plan to support minimum Android N, Spring Framework 5 uses Reactor and can directly translate to RxJava transparently. I think we are going to be successful together in accumulating knowledge from RSC/reactor and rxjava, we have a solid Java answer to reactive programming and reactive streams, finally. |
|
+1 on your plan, and happy to see that under your leadership the pace will pick up again. |
|
👍 Your plan looks good. |
|
+1 Its great to see that things will start moving again ! |
|
Very glad to see major movements in RxJava again. Looking forward to seeing awesome results! 👍 |
|
Congratulations David, I think the project is in great hands! |
(emphasis mine) Did 1.1 remove deprecated APIs from 1.0.x? This is a breaking change for consumers that may surprise. Isn't RxJava's goal long-term compatibility. |
|
I agree with Jake. Seems unnecessary to remove the deprecated APIs unless absolutely necessary, especially if you're eyeing RxJava 2.x only a few months later. |
|
@JakeWharton yes a few methods where deleted between 1.0 and 1.1. They were:
Only methods marked @Experiment/@beta AND @Depericated are eligible for removal. |
|
Thanks for the clarification. 👍 On Fri, Jun 17, 2016 at 1:55 PM George Campbell notifications@github.com
|
|
My original intent was to remove anything marked
I assumed these would be low impact and free some room for 1-2 future operators if need to be. However, if you think the support should stay for everything non beta/experimental I 1.x, then be it. |
|
@akarnokd I'm fine with deleting those in 2.x but currently the set of methods deprecated and beta/experimental is:
https://github.com/ReactiveX/RxJava#versioning
|
|
Right, thanks. |
As a newly named lead contributor, I suggest the following policies and future plans regarding RxJava.
RxJava 1.x
The 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:
Trivial PRs
Trivial PRs no longer require at least 2 👍 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.
Since 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.
Bugfixes
If 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 👍 is required for merging.
If the bugfix involves surface API changes, at least 2 👍's are required. If the proposer of a PR is a collaborators, that automatically counts as 👍
If 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 👍 as equal to the 👍's of the core collaborators.
When 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 inReplaySubject; low impact bug: missing argument validation.)If 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.
Performance enhancements
If a PR contains performance enhancements and no surface API changes, collaborators are allowed to merge the PR without the need for additional 👍 provided there is at least one other person (collaborator, the poster of the original issue or other contributors) confirming the improvements.
API enhancements
There are usually 2 complaints with RxJava's API: "it has too many methods/operators but doesn't have my operator".
On 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,composeandextendallow adding operators with minimal inconveniences.On 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.
To avoid these problems, enhancement PRs require at least 2 👍 from the collaborators. If the proposer is also a collaborator, the PR still requires at least 2 👍 from the other collaborators.
If such a PR doesn't get the required 👍 (and thus merged) within two consecutive releases, the PR can be closed by any collaborator.
Issues
Issues 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.
Bug reports should be closed if the fix PR has been merged or rejected without any alternative fix.
Issues 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.
Issues related to feature requests or enhancement proposals can be closed after 30 calendar days and if two or more 👎 has been signalled.
Patch releases
As 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.
Medium or high impact bugs and enhancements can be released sooner, provided at least 2 👍 is received for a release proposal.
Since a release involves updating the
CHANGES.md, 👍 on the related issue and PRs all count towards the minimum 2. (I.e., no need to 👍 both the issue and the PR actually changing the file).Release 1.2
The 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.
Following 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.
I'll distribute a questionnaire regarding the API promotion/demotion to the collaborators and also publish it publicly.
RxJava 2.x
Although there is a working RxJava 2.x branch, its architecture is quite outdated.
The new architecture, as described in Design.md focuses on performance and reduction of object allocations whenever possible.
Switching 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.
Adding operator-fusion won't block release candidates and can happen incrementally.
This is my proposed schedule for 2.0:
Other responsibilities of mine
You 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.
In 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).
Lastly, 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.)
Although tedious at times, I don't expect any interference on this regard and can focus on leading RxJava.
The text was updated successfully, but these errors were encountered: