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

display-parent-updates follow-up #1025

Open
cachescrubber opened this issue Nov 17, 2023 · 2 comments
Open

display-parent-updates follow-up #1025

cachescrubber opened this issue Nov 17, 2023 · 2 comments

Comments

@cachescrubber
Copy link
Contributor

display-parent-updates follow-up

First of all thank you for taking care of my PR #1016!

I noticed it has been release as 2.16.2 but I used 2.17.0 in at-since javadoc comments. If you care, I could file another PR to fix this. Just let me know.

Also I would like to discuss two ideas I had while implementing #1017.

Display- vs update goals.

For the display-*-updates goals which correspond 1:1 to an update-* goal - would't it make sense to replace the display goal with an additional property (displayOnly, or dryRun) in the update goal? This would eliminate a lot of duplications.

Mojos/Goals we could refactor accordingly would be imo

  • update-parent and display-parent-update
  • update-properties and display-property-updates

Adopt Reports to the concept of Segments

org.codehaus.mojo.versions.api.Segment

Instead of filtering versions like in the display or update goal, I would suggest to report per Segment:

Example:

Current Version: 1.2.3

Latest Increment update: 1.2.4
Latest Minor update: 1.3.7
Latest Major update: 2.0.1

@jarmoniuk
Copy link
Contributor

jarmoniuk commented Nov 18, 2023

Hi there.

For the display--updates goals which correspond 1:1 to an update- goal - would't it make sense to replace the display goal with an additional property (displayOnly, or dryRun) in the update goal? This would eliminate a lot of duplications.

Implementation-wise, that would make sense indeed. However, most users don't pay close attention to changes in plugins as they mostly have them plugged into their CI/CD pipelines. Removing a goal or changing option semantics (even preceded by a deprecation) would eventually cause a barrage of bug reports with complaints about broken pipelines.

So, personally, I wouldn't introduce any breaking usage changes.

@slawekjaranowski
Copy link
Member

I noticed it has been release as 2.16.2 but I used 2.17.0 in at-since javadoc comments. If you care, I could file another PR to fix this. Just let me know.

I had a plan to bump project version to 2.17.0 .... but forgot about it, @olamy release next version as is ....

Master version should be always ready for release without magic - so it was my mistake 😢

Now we can update since tags to corresponding correct version 2.16.2 and with next release documentation will be ok.

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

No branches or pull requests

3 participants