There are some really interesting versioning issues in the rxjava github repo pertaining to how to handle rxjava version 2.
- Not break everything with pushing an update
- Not forcing people to update
Problems that need to be addressed as a result of the goals:
- Allow use of multiple version of the library
The first problem sounds easy, just bump the version number and let people upgrade. But there are more problems, and they fall into two groups problems with dependency management(e.g. which jar to pull) and source code conflicts, e.g. the next version doesn’t have the same api interface.
Handling the Dependency problem:
Dependency problems arise when two of your libraries are require different versions of a library. E.g. one library requires RxJava v1 and another library requires v2.
Which would roughly yield something like the following:
compile 'io.reactivex:rxjava:1.x.y' compile 'io.reactivex:rxjava:2.x.y'
This might look good, but from the issues discussed it doesn’t work as the 2.x.y version would be the only one that gets included.
The solution proposed is to use different group ids in maven(specifically postfix the group id with the version number). This allows the two dependencies to be used side by side.
The second problem was pertaining to conflicts in the code base. The use case presented for this problem was my code base is large, and upgrading from one version to the other will take significant time. Allowing two version of the library to exist side by side allows for a gradual upgrade.
The second problem is solved by changing the package name. This is perfect in that individual files can be updated to use the new library one at a time. Heck if there is a problem in a file even both libraries could be used side by side by taking advantage of the package name.
Both goals are achieved with this. One side note on the second goal is that sometimes users can’t upgrade. E.g. RxJava v2 requires Java 8, the android platform is Java 7. As of now Android developers wont be able to use RxJava v2.