Should we keep Readium modules' versions synchronized?

[mickael-menu]

UPDATE: This question is obsolete now that we have a single repository. All the modules are released together.

For the whole 2.0.0 early release path, we kept the versions of all Readium modules in sync. This helped prevent too much issues with incompatible changes.

Now that the 2.0.0 toolkit reached a stable point, if we don't mess up with semantic versioning every minor versions should be compatible with each other.

So should each module be released independently until we move to 3.x?

Pros

• We can release bugfixes (patch versions) much quicker, since we don't have to wait for significant enough changes across several modules.
• Minor versions will be less time consuming to release, so probably more frequent too.
• No more awkward empty changelogs for modules that are rarely updated.

Cons

• Some features are often spanning several modules, so it will be less clear which versions you need to fully enable a particular feature (e.g. audiobook support).
  • We can circumvent this issue by keeping the major and minor versions synchronized, but keep the patch free (e.g. 2.1.+)
• On Android, it's frequent to have a single version for all the modules of a particular library, which allows to write:

  final r2_version = '2.0.0'
  implementation "com.github.readium:r2-shared-kotlin:$r2_version"
  implementation "com.github.readium:r2-navigator-kotlin:$r2_version"
  implementation "com.github.readium:r2-streamer-kotlin:$r2_version"

  • However, it does not matter that much in practice.

Vote

State one or two preferences as a reaction to this thread. Votes will be pondered in the final decision, but will not enforce it.

• ❤️ Keep all module versions synchronized
• 🚀 Keep only the major and minor versions synchronized (e.g. 2.1.+)
• 🎉 Keep only the major versions synchronized (e.g. 2.+)

[mickael-menu]

• On Android, it's frequent to have a single version for all the modules of a particular library, which allows to write:

  final r2_version = '2.0.0'
  implementation "com.github.readium:r2-shared-kotlin:$r2_version"
  implementation "com.github.readium:r2-navigator-kotlin:$r2_version"
  implementation "com.github.readium:r2-streamer-kotlin:$r2_version"
  

To go in more depth, Gradle actually supports dynamic versions, so one could write this to get all patch versions of the 2.1 releases:

final r2_version = '2.1.+'
implementation "com.github.readium:r2-shared-kotlin:$r2_version"

However, this is actively discouraged by Google because Gradle will automatically upgrade to the latest possible versions, making it difficult to have reproducible builds.

Caution: When specifying dependencies, you should not use dynamic version numbers, such as 'com.android.tools.build:gradle:3.+'. Using this feature can cause unexpected version updates and difficulty resolving version differences.
https://developer.android.com/studio/build/dependencies

Now I think this could actually be solved by locking the dependencies with Gradle. But it's such a fringe Gradle feature in Android development that I'm not sure we should promote it.

[mrifni]

"My vote is for Keep only the major versions synchronized " Also would like frequent minor releases whenever there is a fix or improvements is merged to develop branch, so it enables external integrators like me to implement and test quicker.

[stevenzeck]

I'm torn between this. I like being able to specify a version for a "common" library, as you show in the cons section. If I need Android Room, I put this in my gradle file:

implementation "androidx.room:room-runtime:$room_version"
implementation "androidx.room:room-ktx:$room_version"
kapt "androidx.room:room-compiler:$room_version"

A release is done for all of those at the same time. I don't know if they all always have changes, or if they just do a blank release to keep them synchronized.

On the other hand, I imagine it's probably a pain to do a release if one module needs a simple bug fix. I think at the very least the major versions should always be the same. Otherwise I'm indifferent to the rest.

[mickael-menu]

Looks like the major + minor versions will stay synchronized. So you should still be able to use this technique if you're okay waiting for minor releases to get bugfixes.

Regarding the Room example, they have a single changelog for all the Room modules, so that helps against weird empty changelogs like we have on r2-opds. Also Jetpack is a mono-repo which probably simplify making synchronized versions.

We can revisit this issue if/when we resolve the mono-repo discussion.