You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
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 anupdate-*
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
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
The text was updated successfully, but these errors were encountered: