Support and Deprecation Lifecycle

[benjchristensen]

What should the support lifecycle be for RxJava?

Guava is one example that communicates clearly up front what to expect: https://github.com/google/guava#important-warnings

It probably makes sense for any major version to be supported for at least 2 years. Should it be longer? Or do we need to guarantee this namespace (rx.*) will never break once we release 1.0? I'd appreciate feedback on this.

RxJava intends to be something that can be relied upon deep in a tech stack and included in public APIs without fear of breaking or conflict (once we hit 1.0).

Does this mean we should never release a 2.0 in the same namespace? Or can we at some point (such as when Java 9 comes out) have a 2.0 that uses the same namespace?

[uweschaefer]

i'd appreciate different namespaces. The "extra burdon" of changing an import and recompiling isn't that big and makes migrating to another major version a conscious decision.

[JakeWharton]

Even if the burden was high I don't think that's an issue.

The value proposition of a package-changing version 2 would have to be extremely high to justify a package name change. It effectively renders all libraries and consumers of the v1 API instantly useless in that new world. Granted, a shim could be provided where appropriate.

I'd almost argue that it's much more nuanced.

There's a very specific core contract that will be used in so-called upstream dependencies (mostly creating observables and simple transforms). This differs from so-called downstream dependencies which will likely be leaning much more heavily on the operators and scheduler interaction.

You would never want to break the former case, but a 2-year deprecation of the latter case isn't so bad. Of course, this brings up a discussion of where exactly the line is between the two is to which I have no idea.

Because of this I'll lean heavily on the long-term deprecation strategy with a generous helping of common sense thrown in to try and not break the bits which are most likely to be used by the aforementioned "upstream" use-cases.

Only if an extremely strong value proposition presents itself do I think a hard rx2.* is warranted. For example, Java 10 is likely to include value types and generics over primitives which might just be that exact value proposition. Or hey, maybe it will be clever enough to fit nicely into the current API.

[benjchristensen]

Thank you both for your feedback.

The value proposition of a package-changing version 2 would have to be extremely high to justify a package name change. It effectively renders all libraries and consumers of the v1 API instantly useless in that new world.

Agreed.

Only if an extremely strong value proposition presents itself do I think a hard rx2.* is warranted.

I also agree with this. At this point the only types of things I'm currently aware of that may warrant this are something like value types in Java 9/10 (and thus bumping up from our current Java 6 support) or standardization of interfaces in the JDK that we should support. Other possibilities over time are advances in design or Java itself that would enable much faster implementations (such as reduced object allocations). We can always repackage to something like io.reactivex.Observable but it comes at the high cost of rendering all v1 and v2 libraries effectively incompatible with each other.

This is a premature discussion, but I wanted to set the stage early and be clear that I am intending on long-term stability while also wanting to have a framework for thinking about possible changes in the years to come as things always advance and improve.

[roman-mazur]

Actually even new API that relies on new language features might be managed without breaking compatibility and released as separate packages depending on the core. Something like io.reactivex:rxjava-java10. And the core might be updated to make it possible to plug a more efficient implementation depending on a new Java version.

[daschl]

I think keeping 1.0.* alive for at least two years (and making it clear) will make it easer to make business decisions for potential users.

From my experience, it doesn't make much sense to think upfront what should change on a new major version (just the version, namespace,..) but once the time is there I think it will naturally align because:

• we can identify on which versions users are
• we can identify what needs to be changed and what impact that has
• in what ways backwards compatibility can be provided

For the 2.0 Couchbase Java SDK we went down the path with an artifact rename (for some other reasons) and a different package name, because we explicitly got the request people want to run everything side-by side and upgrade slowly. But we only took the shot because we nearly replaced all the API so people need to rework their apps anyway. So my point is: we don't know right now what will change, so its hard to justify how that big shift should happen.

I think right now the most important thing is to work out the semantics for minor and bugfix releases (release cadence) as well as how long people can expect to work on the 1.x branch.

[benjchristensen]

how long people can expect to work on the 1.x branch.

This is I believe the most important part and it seems we need to plan for at least 2 years. It doesn't mean it needs to be a rapid release cycle once functionality additions calm done, but stable and supported. The intent of RxJava is to be a stable, small(ish) core that other libraries can build upon. Due to this the stability of the library is key.

Is 2 years long enough to be counted upon? I have no idea if we'll even have reasons to break things in a few years, but what timeframe is needed to feel "stable"?

As an aside, I'm acutely aware of how painful it is to upgrade a company using a library like this. If we ever do an RxJava 2.0 it would be a massive breaking change for all of Netflix and thus would almost certainly mean we use new namespacing.

I suppose we can stop mulling over a future we can't predict ... thanks for your inputs though, it helps me reason about this and better answer the questions when I'm asked.

[daschl]

@benjchristensen that sounds very reasonable, thanks much.