Actually you only need to do this: 1. mvn release:prepare -DautoVersionSubmodules=true 2. mvn release:perform
(In the perform the release plugin is configured in the apache parent to automatically select the "apache-release" profile) As soon as releaae:perform is executed the release is done and therefore it is cleaned up ... a RC2 is a completely new release. I guess you added the "-P apache-release" in the prepare step to get the release artifacts in the target directory. However you should stage the artifacts in "target/checkout/target" instead. You don't need to manually change the version back as the release:prepare asks you for the two versions. Just re-enter the version and the release version and you should be ready to go. Chris Am 13.10.19, 02:18 schrieb "Xiangdong Huang" <[email protected]>: Hi, > I am not quite sure, but I guess when preparing the release the steps haven't been executed as written in the RM guide. When release RC1, I ran: 1. mvn release:prepare -P apache-release -DautoVersionSubmodules=true 2. mvn release:perform -DreleaseProfiles=apache-release Because RC1 has some other issues, I had to prepare RC2. Then I found that I can not run `mvn release:rollback` (because all pom.xml.releaseBackup had been cleaned automatically). So I checked rel/0.8's latest codes from the repo (and the version was changed to 0.8.2-SNAPSHOT by the `mvn release:perform` command). I had to change the version number back to 0.8.1-SNAPSHOT and then run `mvn release:prepare` and `mvn release:perform` once again. That is all what I did using maven... Is there something incorrect? One more thing, I checked the RC1 source-release.zip file[1], the maven-wrapper.jar also exists... [1] https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.1/rc1/apache-iotdb-0.8.1-incubating-source-release.zip Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Christofer Dutz <[email protected]> 于2019年10月12日周六 下午7:30写道： > Yeah ... I wanted to say, the .gitignore helps preventing to accidentally > check it in, but it doesn't automatically exclude it from the source > assembly. > > Guess I never before used the maven wrapper for building a release (Always > have maven installed) ... > > But thinking about it ... this file actually should never have been there > in the first place ... > The release plugin does the preparing of a release (change the version to > a non-SNAPSHOT version) and then tags this version and then changes to the > next development version and checks both in. > The actual release is then built during the release:perform step by > checking out this tag from git into an empty "target/checkout" directory > and spawning a new maven build in that directory (without the maven > wrapper). > So this jar shouldn't have been there, as it is only downloaded when > running maven manually using the mvnw script, which the release:perform > goal of the release plugin doesn't do. > > I am not quite sure, but I guess when preparing the release the steps > haven't been executed as written in the RM guide. > Using it, the file shouldn't have been there and there shouldn't be the > need to adjust the assembly descriptor to exclude that file. > > Chris > > > > > > Am 12.10.19, 05:56 schrieb "Willem Jiang" <[email protected]>: > > en, Justin, you are right. We need to update the distribution assembly > file at the same time. > I just update the JIRA issue about this. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sat, Oct 12, 2019 at 10:22 AM Justin Mclean < > [email protected]> wrote: > > > > HI, > > > > > For the jar in the source release, we could address it by adding > below > > > line into .gitignore file. > > > #skip the maven-wrapper.jar > > > .mvn/wrapper/maven-wrapper.jar > > > > How would that fix it? The release needs to be be made on on the RM > machine not from guthub and GitHub doesn’t currently have that jar. [1] > > > > Thanks, > > Justin > > > > 1. > https://github.com/apache/incubator-iotdb/tree/master/.mvn/wrapper > > >
