On 30 August 2018 at 11:19, Thomas Vandahl <t...@apache.org> wrote: > On 28.08.18 12:03, sebb wrote: >> On 28 August 2018 at 09:25, Mark Struberg <strub...@yahoo.de.invalid> wrote: >>>> This is unlikely to happen as long as it does not cover multi-module builds >>> >>> The maven-release-plugin covers multi-module releases since many years. >>> >>> In the projects I'm working on there is no 'release manager'. >>> _Everybody_ can do releases without having to know anything special. >>> This is where the maven-release-plugin really shines. >>> Just use mvn release:prepare + mvn release:perform and be done. >> >> If it works first time. > > I think the release plugin does quite a good job in resuming broken > build processes, rolling back etc.
Only for the RM. Meanwhile, trunk has been changed. >> >> The problem is that the Maven release plugin design assumes that the >> first release attempt will succeed. >> As such, it updates trunk to the new snapshot version. >> (This causes issues with CI builds) > > You are free to choose whatever developmentVersion should be recorded. It should not be necessary to downdate the new version. >> It also assumes that the current workspace does not contain anything >> it should not. > > I actually consider this an advantage. It helps you to avoid > inconsistent source trees. Huh? If a local workspace contains spurious files, by definition it is inconsistent. > If you want to get around this, see > checkModificationExcludeList of the prepare goal. Again, it should be the default to use a clean checkout of the tag for building the binary/source artifacts. > Bye, Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
