Revisit ExperimentalObservable

[zsxwing]

I just found one issue about the idea of ExperimentalObservable. If we want to move some mature method from ExperimentalObservable to Observable, we have to break the binary compatibility. Thoughts on how to solve it, or this is not a good idea and we should use RxJava's @Beta/@Experimental?

[zsxwing]

Another disadvantage of ExperimentalObservable is that because overload and implicit conversion cannot work together, sometimes we need to rename the method to make the compiler happen. See #151

[samuelgruetter]

Maybe we should just move everything from ExperimentalObservable into Observable. The only problem then is how to mark it, because AFAIK, method annotations are not shown in scaladoc. But we could just mark the experimental methods in the documentation, maybe with the same red badge as here, but put it per method instead of per class. That's just one line of HTML, should be easy to use.

[jbripley]

I did some work to update to RxJava 1.0.10, which adds a bunch of @experimental methods to Subject. I followed the example of ExperimentalObservable, which in this case meant adding ExperimentalSubject, ExperimentalAsyncSubject etc. which felt a bit unwieldy.

Start using @Experimental/@beta in RxScala as well might be the better solution.

Also, I looked into adding RxScala support for the proposed AbstractProducer, which meant adding an object ExperimentalObservable for the create()/apply() methods. Moving those methods later would mean breaking source compatability as well.

[zsxwing]

OK. Let's move everything to Observable and use @Experimental/@Beta.

[zsxwing]

Looks some css style bug in the Scala doc. The EXPERIMENTAL labels in this page are really weird: http://www.scala-lang.org/api/2.11.6/scala-reflect/index.html#scala.reflect.api.package

[samuelgruetter]

Seems to be a problem only if there's no scaladoc, as here:

But if you add some doc comment, it looks fine:

[zsxwing]

Closed. It's resolved in 0.25.0.