In the context of an "early" release, evaluate whether to revert the Fabric8 Maven plugin integration removal

[fabiobrz]

Issue Overview

We might want to release a CR build "early", in order to resume the project status.
In such a context, it could be useful to cut the final changes to the bare minimum, and let replacements happen asynchronously.

Recently, we've merged changes to the Fabri8 Maven Plugin integration, being such plugin deprecated, in order to have future replacement with the JKube Maven plugin.

This completely makes sense, but we should discuss whether to revert such changes to release something we can start use somewhere early enough, and implement the replacement with JKube separately, or whether the current implementation is in a good enough shape to be finished, i.e. the replacement is tested and documented.

Expected Behaviour

Although being deprecated, an early-cut release should still provide integration with the Fabric8 Maven Plugin

Current Behaviour

Changes in 11408cb should be verified by running the related integration tests.

Steps To Reproduce

1. mvn clean verify # and check all the related tests

Additional Information

N/A

[jimma]

@fabiobrz We can create a 1.x branch and tag several 1.x maintainance release instead of reverting these changes. WDYT?

[fabiobrz]

@fabiobrz We can create a 1.x branch and tag several 1.x maintainance release instead of reverting these changes. WDYT?

Hi @jimma - +1, that's one of the two options I started thinking of soon after @gaol and I discussed the topic, yesterday, based on the suggestion this would avoid the maintenance burden on main.
That being said we'll have to backport any relevant fix between branches, but yeah - it seems doable given the current throughput 😇
In case we have this decision confirmed, then we can create the branch as soon as we have restored the OpenShift integration tests, IMO.

[jimma]

@fabiobrz I prefer only backporting some important/required fix to the old 1.x branch and 2.0(main) branch would be our focus ,the 2.0 version is what we should suggest user to upgrade once we get it out.

[fabiobrz]

@fabiobrz I prefer only backporting some important/required fix to the old 1.x branch and 2.0(main) branch would be our focus

Can be tricky, a lot of changes went in, and those are needed to execute integration tests, which in turn is a requirement in order to release. But we can try. Let's discuss any details and potential implications in chat 🙂

the 2.0 version is what we should suggest user to upgrade once we get it out.
Sure, +1.