Preserve API compatibility between and across releases

[Alexander--]

Removal of things like old ViewObservable methods and moving stuff around is cool and all, but doing so makes all library users (myself included) rewrite lots of code for what amounts to someone's deep self-satisfaction and ~3Kb of code size benefit (with later being nullified by Proguard anyway). I know, that RxAndroid is still a pre-release software, but please at least keep things deprecated for couple of releases before throwing them out of window, especially, when there is a little reason for change besides aesthetics.

[JakeWharton]

We cannot and will not guarantee this--especially since RxJava is already stable. The only reason to upgrade RxAndroid at this time is explicitly opting into the new version which will comes with changes, mostly mechanical. Not only is this library finding it's voice and thus no API can be considered stable, but API aesthetics are extremely important to me. Everyone will suffer now so that post-1.0 we can have little to no changes.

[Alexander--]

API aesthetics are extremely important to me

Same here. But temporarily keeping deprecated methods without breaking compatibility sounds like huge part of aesthetics for me. It is also a nice way to get some feedback from those, who don't monitor your repository on daily basis (instead of them quietly rolling out their own libraries to do things in their most aesthetic way).

is this library finding it's voice and thus no API can be considered stable

Ok, will you accept a merge request to get some ViewObservable methods back there? Generating an event object with entire TextView text on every entered symbol sounds like amazing way to trash device RAMs, does not it?

[JakeWharton]

get some ViewObservable methods back

Like what? I don't use ViewObservable.

[omo]

Some were moved to WidgetObservable.
I think it's fine to keep some deprecated method, as we already do it for schedulers. Probably we could keep these deprecated thing while pre-1.0 and let them go on 1.0?

[JakeWharton]

Some breaking changes are unavoidable. We'll try to keep old APIs for at least one minor.

[JakeWharton]

Also, I just removed the deprecated schedulers in #97 since it's been a whole year.

[dlew]

We should take aims to explain all breaking changes in the CHANGELOG though, which we haven't been very good about so far. But I agree that we're in "break things" mode right now, for the better good of the initial release.

[hamidp]

@Alexander-- It is a pain to have to update code often, but it is not for self-satisfaction. The cost of API changes is the lowest now while everything is still in flux. The straightjacket of API stability this early on would really slow things down and produce an unwieldy library.

[Alexander--]

The cost of API changes is the lowest now while everything is still in flux.

I don't care, when it is about renaming/moving/reordering. But adding/replacing functionality is usually orders of magnitude harder than temporarily keeping stuff around. Why not do it then?

get some ViewObservable methods back

Like what? I don't use ViewObservable.

I have submitted #100.

Some breaking changes are unavoidable. We'll try to keep old APIs for at least one minor.

Sounds reasonable. If no one have objections, feel free to close the issue.