2.0 Package Name

[benjchristensen]

I've been using io.reactivex as the assumed package name for v2, but that doesn't have to be what it is.

RxJava v1 ==> rx

We could do any of the following (or something else) for RxJava v2:

• rx2
• io.rxjava
• io.rxjava2
• io.rx2

The thinking behind this is keeping our options open for a v3 years from now (say after Java 10).

Let's assume we have 3 versions and want to decouple the upgrade cycles, it would look like this:

io.reactivex:rxjava:1.x.y – package rx.*
io.reactivex:rxjava2:2.x.y  – package rx2.* or io.reactivex.* or ???
io.reactivex:rxjava3:3.x.y  – package rx3.* or ???

I'd appreciate input on how this should be done as we'll have to live it with for many years.

Note that this is related to the discussion in #3170 where we are discussing having v1 and v2 as independent artifacts so an app could use both at the same time.

[benjchristensen]

/cc @ReactiveX/rxjava-committers @JakeWharton @davidmoten @simonbasle @alkemist and any others who may have an opinion on this.

[benjchristensen]

rxjava.io is owned by Netflix, so we can use io.rxjava
rxjava2.io and rxjava3.io are owned by me in case we wanted to use them.

Are there others we should pick up in case we need/want them?

[JakeWharton]

Using io.reactivex would definitely put the library in an awkward place for a v3.

I'm not opposed to rx2 despite versioned packages being somewhat of a rarity (counter example: Apache commons-lang3). It also has the bonus of retaining the aspect of being short. When there's clashes in an import scope, fully-qualifying becomes not only easy but also very explicit:

// RxJava1 in an RxJava2 world
Observable<Magic> moreMagic(Observable<Magic> magic) {
  rx.Observable<Magic> oldMagic = getOldMagic();
  return Observable.merge(magic, RxConverter.to2(oldMagic));
}

or conversely:

// RxJava2 in an RxJava1 world
Observable<Magic> moreMagic(Observable<Magic> magic) {
  rx2.Observable<Magic> newMagic = getNewMagic();
  return Observable.merge(magic, RxConverter.to1(newMagic));
}

[daschl]

I'm a little torn on putting the version of the package in the artifact id, since it's not really the place where it belongs.

@benjchristensen do you see the use case that people use the old and new rx versions side by side? For example with couchbase we had that explicit use case requested, so we went with a different artifact ID and the namespace was also different. But every project might be different in that regard.

[benjchristensen]

Yes, using side-by-side is expected for some time, especially in big companies.

For example, using the current Couchbase client, Hystrix 1.x, or RxNetty 1.x with RxJava v1 while starting to use newer libraries, such as those I'm working on at reactivesocket.io which natively use Reactive Streams interfaces (and eventually Java 9 Flow).

Also, v2 will be Java8+ so any library need <8 will stay on v1 and we don't want to prevent people from using libraries taking advantage of Java 8+ just because 1 library needs to stay on 6 or 7.

[jkschneider]

@JakeWharton Unfortunately, virtually nobody uses commons-lang3, even four years later. We should approach these decisions cautiously. Because of the relocated coordinate, there is absolutely no incentive to upgrade to CL3.

[simonbasle]

I don't recall an example out there from the top of my head that puts version number in the package name (although @JakeWharton mentioned apache commons lang3), so no real comparison point.
I agree with the point made by Jake on conciseness to help make code live side by side, so maybe rx2 is a good choice?
Another solution can maybe be to include the major version number as another level of prefixing, ie io.reactivex.v2 or something like that?

[benjchristensen]

A related post is at #3170 (comment) about the maven artifactId name. I have been convinced that we should retain rxjava as the artifactId and just have an option for pulling in v1 with a different artifactId such as rxjava_v1 for those who do need both.

As for the package, I'm still leaning towards io.reactivex and not putting the version in the package name.

io.reactivex:rxjava:1.x.y – package rx.*
io.reactivex:rxjava:2.x.y – package io.reactivex.*
io.reactivex:rxjava:3.x.y – package io.rxjava (or some other made up name, or back to rx.*)

👍 👎 ?

[simonbasle]

👍, double maven publication sounds like a great solution IMHO

[daschl]

👍

[benjchristensen]

Thanks for the positive feedback @simonbasle and @daschl

@ReactiveX/rxjava-committers I'd appreciate your vote on this.

[zsxwing]

👍

[ldaley]

Interesting discussion. I don't have any unique input.

[akarnokd]

I'm closing this for now.

2.x will go with io.reactivex.rxjava2:rxjava:2.x.y pattern and packages start with io.reactivex. We can revisit the latter organization in the RC timeframe once others start to adapt and give feedback.