Am Do., 30. Aug. 2018 um 13:45 Uhr schrieb sebb <seb...@gmail.com>: > 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. >
Please note, that all what you are saying is just your opinion on how a release should be created. The maven team clearly has another opinion on that. Both are valid. Our release process is cumbersome and fragile leading to all release looking a little different from each other, depending on who is RM. The pain that our release process causes has been brought up again and again since I started here at commons back in 2011. I wonder whether it is a good idea to use a tool like maven that is pretty opinionated on how to do things and then bend it to do it another way. Maybe we should simply use maven the way it is intended. Or if we can't live with the way maven does things, maybe we should use a tool that gives us more liberty in customizing the build, e.g. gradle. Benedikt > > > 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 > >
