New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.0 Package Name #3173

Closed
benjchristensen opened this Issue Aug 21, 2015 · 14 comments

Comments

Projects
None yet
8 participants
@benjchristensen
Member

benjchristensen commented Aug 21, 2015

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 benjchristensen added this to the 2.0 milestone Aug 21, 2015

@benjchristensen

This comment has been minimized.

Show comment
Hide comment
@benjchristensen

benjchristensen Aug 21, 2015

Member

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

Member

benjchristensen commented Aug 21, 2015

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

@benjchristensen

This comment has been minimized.

Show comment
Hide comment
@benjchristensen

benjchristensen Aug 21, 2015

Member

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?

Member

benjchristensen commented Aug 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Aug 21, 2015

Member

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));
}
Member

JakeWharton commented Aug 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@daschl

daschl Aug 21, 2015

Contributor

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.

Contributor

daschl commented Aug 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@benjchristensen

benjchristensen Aug 21, 2015

Member

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.

Member

benjchristensen commented Aug 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jkschneider

jkschneider Aug 21, 2015

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

jkschneider commented Aug 21, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@simonbasle

simonbasle Aug 21, 2015

Contributor

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?

Contributor

simonbasle commented Aug 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@benjchristensen

benjchristensen Aug 27, 2015

Member

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.*)

👍 👎 ?

Member

benjchristensen commented Aug 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@simonbasle

simonbasle Aug 27, 2015

Contributor

👍, double maven publication sounds like a great solution IMHO

Contributor

simonbasle commented Aug 27, 2015

👍, double maven publication sounds like a great solution IMHO

@daschl

This comment has been minimized.

Show comment
Hide comment
@daschl

daschl Aug 27, 2015

Contributor

👍

Contributor

daschl commented Aug 27, 2015

👍

@benjchristensen

This comment has been minimized.

Show comment
Hide comment
@benjchristensen

benjchristensen Aug 27, 2015

Member

Thanks for the positive feedback @simonbasle and @daschl

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

Member

benjchristensen commented Aug 27, 2015

Thanks for the positive feedback @simonbasle and @daschl

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

@zsxwing

This comment has been minimized.

Show comment
Hide comment
@zsxwing

zsxwing Aug 28, 2015

Member

👍

Member

zsxwing commented Aug 28, 2015

👍

@ldaley

This comment has been minimized.

Show comment
Hide comment
@ldaley

ldaley Sep 8, 2015

Contributor

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

Contributor

ldaley commented Sep 8, 2015

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

@akarnokd akarnokd modified the milestones: 2.0 RC 1, 2.0 Jun 19, 2016

@akarnokd

This comment has been minimized.

Show comment
Hide comment
@akarnokd

akarnokd Jun 19, 2016

Member

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.

Member

akarnokd commented Jun 19, 2016

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.

@akarnokd akarnokd closed this Jun 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment