|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [mojo-dev] [jira] (MVERSIONS-214) support semantic... Andrei Pozolotin (JIRA)
- [mojo-dev] [jira] (MVERSIONS-214) support sem... Tuomas Kiviaho (JIRA)
- [mojo-dev] [jira] (MVERSIONS-214) support sem... Stephen Connolly (JIRA)
- [mojo-dev] [jira] (MVERSIONS-214) support sem... Stephen Connolly (JIRA)
- [mojo-dev] [jira] (MVERSIONS-214) support sem... Tuomas Kiviaho (JIRA)
- [mojo-dev] [jira] (MVERSIONS-214) support sem... Stephen Connolly (JIRA)

Oh no what have I done![]()
I'm personally only interested on POM mutilation without bells and whistles that plugins such as clirr, jardiff, aries versions and semver enforcer rule provide already. I'd be happy without adding any extra goals such as verify and only ask whether or not it would be possible to improve version ranges support under this issue (or should I open a new one).
Currently it's not possible to preserve ranges so that [1.0,2.0) resolutes to [1.2,2) instead of 1.2. Of course it would be nice if comparison rule could be used to determine if the right hand side is to modified or if it would be better to stick with the current version when next release is available but not within the resolution range, but crude bumping of the left hand side version would be beneficial as such. In my mind this kind of behavior that revolves around version number compared to Maven repositories have to offer is what version plugin is all about.