Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fabiobrz opened this issue Oct 7, 2024 · 4 comments

Comments

@fabiobrz
Copy link
Collaborator

fabiobrz commented Oct 7, 2024

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

@fabiobrz fabiobrz changed the title In the context of an "early" release, evaluate whether to resume the Fabric8 Maven plugin integration removal In the context of an "early" release, evaluate whether to revert the Fabric8 Maven plugin integration removal Oct 7, 2024
@fabiobrz fabiobrz added this to the 1.19.0-EA milestone Oct 14, 2024
@jimma
Copy link
Collaborator

jimma commented Oct 15, 2024

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

@fabiobrz
Copy link
Collaborator Author

@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
Copy link
Collaborator

jimma commented Oct 15, 2024

@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
Copy link
Collaborator Author

fabiobrz commented Oct 15, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants