DBZ-5317 Upgrade UI to 2.0

[ani-sha]

https://issues.redhat.com/browse/DBZ-5317

[Naros]

Hi @ani-sha so I looked at the failures, and yes you will need to include a dependency on:

<dependency>
  <groupId>io.debezium</groupId>
  <artifactId>debezium-storage-kafka</artifactId>
</dependency>

The KafkaDatabaseHistory class was moved to this new artifact in Beta1.

[Naros]

Hi @ani-sha this LGTM overall, just a few comments inline and I think we're good.

[rk3rn3r]

Didn't we agree to explicitly depend on 2.0 instead of latest until we manually update? latest might block too many PRs until breaking changes from the main repo are resolved?

That would also mean we checkout a specific tag from core instead of the main branch?

[Naros]

The 2.0 to latest were targetting images that rarely change, zookeeper, kafka, and the example databases. In addition, the latest and 2.0 are synonymous tags anyway, but it just helps minimize the upgrade tasks when we move from 2.0 to 2.1, etc. I'd prefer if we can minimize all the effort involved when new releases go out, that just helps all involved.

[ani-sha]

The 2.0 to latest were targetting images that rarely change, zookeeper, kafka, and the example databases. In addition, the latest and 2.0 are synonymous tags anyway, but it just helps minimize the upgrade tasks when we move from 2.0 to 2.1, etc. I'd prefer if we can minimize all the effort involved when new releases go out, that just helps all involved.

I think we can give this a try. If things don't work that well we can switch back to 2.0 tag anytime. Wdyt @rk3rn3r?

[rk3rn3r]

@ani-sha I don't know if I am wrong here. Let' me try to explain why I feel unsure about using latest: When I look at it from the UI side of things depending on 1.9/2.0/2.1 explicitly (even better more explicitly on 1.9.4, 1.9.5, 2.0.0.Beta1) feels more stable and reliable and even reproducible. I can always be sure that a newly released latest version won't break tests / PRs immediately.
Instead I need to create a manual PR to update to the next latest version and I can fix issues with the PR, I can even ignore broken releases.
For example this is the reason I think is what's causing troubles with the core repo tests: core changes are breaking UI which is breaking core because those 2 repos are not well integrated (because they aren't mono repo) and I don't see that we are able to keep up with the core change rate to keep everything stable. Even more: in the future we need to be able to handle multiple Debezium versions with the UI.

Please correct me when I am wrong, or if you find this is an acceptable situation, then I agree using latest. But if my assumptions are correct I personally prefer the safer and explicit dependency, but I am okay with using latest when you want to keep it now and see how it goes.

[ani-sha]

@rk3rn3r I understand your concern. Then I guess there aren't any changes to make in this PR. Could you go ahead and merge?

[rk3rn3r]

It depends. I would personally make the dependent versions more explicit (2.0.0.Beta1) for example. Chris is more on the latest side. It's up to you how you want to go. Let's wait for @Naros to allay my concerns maybe later.

[Naros]

So to be clear there are two aspects as it pertains to versions.

Image versions in the end-to-end workflow
This is specifically what I think we're referring to, the tag for debezium/kafka, debezium/zookeeper, and the databases. It does not matter whether we use 2.0 or latest in this context, they're the same SHA. The only benefit to using latest is that when we move from one maintenance release to another, there isn't a need to make any changes in the UI repository.

Furthermore, looking to the future with multiple Debezium versions, we would replace latest with a matrix of versions anyway, and in this matrix latest would be one of those. Technically this job could be adjusted to using a matrix build pattern that only uses latest and we can just add more to it in the future when we get to that point.

Explicit micro-releases vs Snapshot
So we have 3 workflows, two in the UI repository, and one in the main repository. The one in the core repository uses the current state of main as a snapshot and builds the UI and then runs its tests. Ideally, this job should run the UI against the current Debezium version, which is 2.0.0-SNAPSHOT to guarantee that we identify if there are any compatibility problems between the core and the UI or vice versa. This means that the UI's pom should reference 2.0.0-SNAPSHOT.

If we pin the Debezium UI's pom.xml to a specific version, such as 2.0.0.Beta1, then that workflow in the core repository is a waste because it's not verifying anything in the context of the core repository at all. We'll never see if a PR to the core repo causes any type of incompatibility because it'll always pass. That's why I mentioned that if we went this route, we should just remove the UI step in the core repository entirely because it serves no value.

This also means that in terms of keeping the UI up-to-date, that will fall out of the purview of the contributors to the core or even those of us who merge changes into the core as we'll have no indicator to tell us that such incompatibility exists.

I think if there is a reason to be sticky to a given version, you could leverage a 2.0 branch where that branch is confirmed to be aligned with 2.0.0.Beta1 and you could use this branch as a means of tracking the sticky versions but allowing the main branch to be fluid so we gain the benefit of keeping it up-to-date as changes in core occur in parallel. This is precisely the same pattern we use in the core repository today with releases.

[rk3rn3r]

Applied. Thx a lot @ani-sha.