embeddedkafka/embedded-kafka-scalafix

Discussion on next steps

francescopellegrini opened this issue · 7 comments

francescopellegrini commented

Refactor

To ensure the smoothest transition we could either

  1. move all classes to the new package and add a package object under the old package containing type aliases and lazy vals referencing the classes in the new one;
  2. or add a package object in the new package referencing the current classes and save the refactor itself for a later release.

Release

We could skip publishing the Scalafix rule to Maven Central for it can be invoked directly from Github.

Do you think this additional step could be too complex for the users?

Docs

We need to add a note on both projects' README mentioning the Scalafix rule, how to use it, and which version of the projects it can be used from.

Visibility

We need to make this repo public, of course. ;)

francescopellegrini commented

I'm testing out the github, http, and file invocations and they are not working as I expected them to.. we should probably rely on the classic Maven Central for distributing the rule. Shall I ask Sonatype to create the project hosting? Actually this should not be required since the group id will be the same.

NeQuissimus commented

If we have a scalafix rule, we have a migration path.
Why the package object? Maybe it is a bit harsh but why not just break everything with a straight-forward package rename and point to the scalafix rule?

francescopellegrini commented

I'm concerned about users whom are not using scalafix in their projects or have little knowledge (or time) to add it. A BC release would allow them to schedule this code migration according to their own roadmap.

NeQuissimus commented

That definitely makes sense, I agree. Just wanted to hear your thoughts :D
That package object should definitely have @deprecated annotations, so users become aware of the change.

I would go for option 1 and have the package object as the deprecated way of accessing classes. There is no real urgency to get a release out, so no reason not to do the main work up-front.

  • 👍1
francescopellegrini commented

Do you think we should wait for a major/minor version of the library to release this change? Currently we're at v2.7.0 for embedded-kafka and v6.0.1 for embedded-kafka-schema-registry (waiting for Confluent to catch up with their release).

NeQuissimus commented

Yeah, I think I would bump the major or version for both. This is the sad thing when you try to align with upstream versions :D
Maybe we announce and schedule the changes for 2.8.0+ and 6.1.0+ ?

  • 👍1
francescopellegrini commented

Embedded Schema Registry will have to wait for embedded-kafka to be released with the new package name, of course.

We can go live with this project in the meanwhile.

  • 👍1