Using RxJava @Beta/@Experimental features in RxScala

[jbripley]

What is the current thinking about using features/methods marked as @beta or @experimental in RxJava and exposing them in RxScala?

For example, I was thinking of doing a PR that would make AbstractOnSubscribe available in RxScala with a more Scala idiomatic API. Is that something that would be accepted or should we wait until the feature is marked non-beta/experimental before exposing them in RxScala.

Downside of exposing beta/experimental methods in RxScala is that we tie each RxScala version tighter to a specific RxJava release, with the upside being of making the beta/experimental features available earlier with a Scala interface.

[headinthebox]

Why don't we add them as extension methods (perhaps using the same markers) so you can import them separately.

[zsxwing]

Downside of exposing beta/experimental methods in RxScala is that we tie each RxScala version tighter to a specific RxJava release, with the upside being of making the beta/experimental features available earlier with a Scala interface.

I think we can document two tables for the API compatibility, one for stable APIs, the other for @Beta/@Experimental APIs. If someone uses any @Beta/@Experimental API, they need to use the exactly same version of RxJava.

[zsxwing]

@headinthebox for the experimental methods of RxJava Observable, I added them as extension methods in RxScala #146. But for the experimental classes, such as AbstractOnSubscribe, I think we can also use RxJava @Beta/@Experimental. Thoughts?

[zsxwing]

Closed. Resolved in 0.25.0