Version 2.x Maven Central Identification

[benjchristensen]

The intent of 2.x is to live side-by-side with 1.x. The package name (io.reactivex vs rx) is insufficient though, as the Maven Central artifactId needs to also be different otherwise both can't be imported. So instead of rxjava should it just be rxjava2 like this?

compile 'io.reactivex:rxjava2:2.x.y'
compile 'io.reactivex:rxjava:1.x.y'

[benjchristensen]

@rspieldenner Rob, I can't figure out what I need to change in the Gradle properties to change the name from rxjava to rxjava2 other than changing "project.name" which also changes everything else.

If I change project.name I end up with this:

/io/reactivex/rxjava2/2.0.0-DP1-SNAPSHOT/rxjava2-2.0.0-DP1-SNAPSHOT.jar

Is that what it should be? Or can it be this somehow with just 'rxjava' in the filename?

/io/reactivex/rxjava2/2.0.0-DP1-SNAPSHOT/rxjava-2.0.0-DP1-SNAPSHOT.jar

[benjchristensen]

Seems that the artifactId is most commonly or always also the prefix for the filename. That suggests something like rxjava2 as above. Changing the complete name would also have the side-benefit of allowing two separate projects with different names in an IDE at the same time: rxjava and rxjava2.

However, I winder about the name rxjava2. If we need to make a 3.x but want to retain the same package names we would be stuck with the artifactId rxjava2 with version 3.x.

Is there a better name to represent this next version of rxjava?

io.reactivex – rxjava2 – rxjava2-2.0.0.jar
io.reactivex – rxjava2 – rxjava2-3.0.0.jar

io.reactivex – rxjava – rxjava-2.0.0.jar (I really wish this could work)

[rspieldenner]

Why wouldn't this "io.reactivex – rxjava – rxjava-2.0.0.jar" work?

On Thu, Aug 20, 2015 at 9:33 PM, Ben Christensen notifications@github.com
wrote:

Seems that the artifactId is most commonly or always also the prefix for
the filename. That suggests something like rxjava2 as above. Changing the
complete name would also have the side-benefit of allowing two separate
projects with different names in an IDE at the same time: rxjava and
rxjava2.

However, I winder about the name rxjava2. If we need to make a 3.x but
want to retain the same package names we would be stuck with the artifactId
rxjava2 with version 3.x.

Is there a better name to represent this next version of rxjava?

io.reactivex – rxjava2 – rxjava2-2.0.0.jar
io.reactivex – rxjava2 – rxjava2-3.0.0.jar

io.reactivex – rxjava – rxjava-2.0.0.jar (I really wish this could work)

—
Reply to this email directly or view it on GitHub
#3170 (comment).

[akarnokd]

A separate project makes things much easier; no need to switch back-and-forth between two branches. We could call it rsjava but I can see the confusion due to the one letter change. Having just rxjava-2.0.0 is also attractive. How about copying the current 1.x to a new project RxJava1 and have the 2.0 start in a cleared out RxJava project?

A separate project has also the benefit of not being intermixed with issues and PRs targeting the two versions.

[rspieldenner]

I think changing the group and artifact name are some of the worst things
you can do. When you do that the 2 versions would no longer participate in
conflict resolution. So a gradle/maven/sbt etc. resolve could pull in 2
different versions of rxjava if you do anything besides moving to
io.reactivex:rxjava:2.x.x

On Fri, Aug 21, 2015 at 1:27 AM, David Karnok notifications@github.com
wrote:

A separate project makes things much easier; no need to switch
back-and-forth between two branches. We could call it rsjava but I can
see the confusion due to the one letter change. Having just rxjava-2.0.0
is also attractive. How about copying the current 1.x to a new project
RxJava1 and have the 2.0 start in a cleared out RxJava project?

—
Reply to this email directly or view it on GitHub
#3170 (comment).

[JakeWharton]

That's the point of the change. They are able to operate next to each other.

On Fri, Aug 21, 2015, 10:04 AM Rob Spieldenner notifications@github.com
wrote:

I think changing the group and artifact name are some of the worst things
you can do. When you do that the 2 versions would no longer participate in
conflict resolution. So a gradle/maven/sbt etc. resolve could pull in 2
different versions of rxjava if you do anything besides moving to
io.reactivex:rxjava:2.x.x

On Fri, Aug 21, 2015 at 1:27 AM, David Karnok notifications@github.com
wrote:

A separate project makes things much easier; no need to switch
back-and-forth between two branches. We could call it rsjava but I can
see the confusion due to the one letter change. Having just rxjava-2.0.0
is also attractive. How about copying the current 1.x to a new project
RxJava1 and have the 2.0 start in a cleared out RxJava project?

—
Reply to this email directly or view it on GitHub
<#3170 (comment)
.

—
Reply to this email directly or view it on GitHub
#3170 (comment).

[benjchristensen]

could pull in 2 different versions of rxjava

@rspieldenner As @JakeWharton said, that's the point. Otherwise as soon as v2 comes out it will break every application and basically be unusable without herculean efforts to upgrade everything from v1 to v2 - and that could only be possible if and once v2 accounts for every piece of functionality v1 had (not necessary a good thing to force upon v2).

RxJava is not a library that hides well, as it is intended to be exposed in the public APIs, and be used for composing libraries and systems together. Thus, a breaking change would mean coordinating all systems and libraries to all upgrade at the same time.

For example, at Netflix we would need to upgrade Hystrix for the entire company at the same time. Not going to happen. I consider this an even harder upgrade than Guava (which typically take many months of effort to upgrade) since Guava generally is not part of our public APIs, just internal implementation details.

An application could have the following dependencies:

io.reactivex:rxjava:rxjava-1.0.14
io.reactivex:rxjava:rxjava2-2.0.0

They would then use different types like this:

rx.Observable (from rxjava-1)
io.reactivex.Observable (from rxjava-2) (or whatever we call the package and class names)

[benjchristensen]

@akarnokd I'm not a fan of splitting the projects. We split the community, lose the collaboration between 1.x and 2.x issues (which will be very common), will end up cross-posting things a lot, and would complicate the branding. The branding includes the Github URL, contributors, forks and stars. Those statistics (as superficial as it sounds) are meaningful. They represent the community around the project. Community, branding and marketing are honestly a massive part of a project like this. The code itself honestly is the easiest part.

[jkschneider]

@benjchristensen There is one alternative since you are also changing source package names which is to retain the same Maven coordinate but also provide a shim library that bridges 2.x functionality to the old package names. Effectively, anybody needing both 2.x and 1.x to coexist would just add an additional dependency on the shim. This is a little more in-your-face and encourages upgrades. Think of the SLF4J Log4J shim as a not-entirely-similar case.

[benjchristensen]

@jkschneider can you give me an example of how that would work? That sounds intriguing.

[benjchristensen]

I think I may understand. Is it as follows?

We could double publish RxJava v1 like this:

• io.reactivex:rxjava:1.x.y
• io.reactivex:rxjava1:1.x.y (or whatever name we want like rxjava-v1 or rxjava_1, etc)

Then we publish v2 as:

• io.reactivex:rxjava:2.x.y

So if someone gets upgraded to v2 and it breaks their world, and they need both to live together, they would have dependencies like:

• io.reactivex:rxjava1:1.x.y
• io.reactivex:rxjava:2.x.y

So, instead of us changing artifactIds for new versions, we actually add one for the old version?

[jkschneider]

@benjchristensen That's right -- the main benefit is a natural bias toward upgrading, especially for first order dependents. Depending on how easy it is to bridge new concepts to old, it may also provide an easy way for you to deliver bugfixes to older uses of the API without working on two distinct core branches of rxjava itself.

Perhaps call it something like io.reactivex:rxjava-compat:2.x.y and have the compat library's version track the version of rxjava itself. After all, the compat shim and rxjava will be feature coupled.