[BUILD-255] Maven version check during release is cumbersome Created: 11/Apr/17 Updated: 05/May/17 Resolved: 26/Apr/17 |
|
| Status: | Closed |
| Project: | Build |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | POMs 33 |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Maxime Michel | Assignee: | Maxime Michel |
| Resolution: | Fixed | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Date of First Response: | |||||||||
| Sprint: | Basel 93 | ||||||||
| Story Points: | 3 | ||||||||
| Description |
|
The check might have been useful at some point, but what I'm seeing these days is that it's terribly cumbersome:
mmuehlebach and I think either of the following should be done:
|
| Comments |
| Comment by Mikaël Geljić [ 12/Apr/17 ] |
<profile>
<!-- a profile used when performing a release -->
<id>release-perform-profile</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<configuration>
<rules>
<requireMavenVersion>
<version>[3.2.3]</version>
</requireMavenVersion>
</rules>
</configuration>
</plugin>
</plugins>
</build>
</profile>
This profile is only used upon release:perform... by design of the release plugin*. Options:
Moving ticket to BUILD if I may |
| Comment by Maxime Michel [ 13/Apr/17 ] |
|
Thanks for the details! I personally wouldn't go for 2. because I consider that things should run smoothly with current Maven versions. The corner case in which somebody ends up stuck in the middle of a module release while using a Maven version from mid-2014 (3.2.2), or older, isn't likely to happen. And if does, then I'd argue it's that person's responsability to upgrade, which is a simple task anyway (simpler and more elegant than a downgrade at least). |
| Comment by Mikaël Geljić [ 13/Apr/17 ] |
|
Absolutely, I actually didn't mean options as mutually exclusive, but the open range seems more sensible first. |