Preserve API compatibility between and across releases about rxandroid HOT 9 CLOSED

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.

from rxandroid.

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?

from rxandroid.

get some ViewObservable methods back

Like what? I don't use ViewObservable.

from rxandroid.

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?

from rxandroid.

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

from rxandroid.

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

from rxandroid.

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.

from rxandroid.

@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.

from rxandroid.

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.

from rxandroid.