LTS Release

Prequisites

Merging before release

Before you make a release you should merge all changes to the master.

Signing Artifacts with GPG

You first need to generate a GPG Key and store it in your .m2/settings.xml.

  <profiles>
    <profile>
      <id>gpg</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <gpg.executable>gpg2</gpg.executable>
        <gpg.passphrase>yourPassPhrase</gpg.passphrase>
        <gpg.keyname>yourGPGKeyName</gpg.keyname>
      </properties>
    </profile>
  </profiles>

MyCoRe-Server & OSSRH Credentials

You need to store your Server credentials to the .m2/settings.xml.

  <servers>
    <server>
      <id>ossrh</id>
      <username>your_ossrh_user_name</username>
      <password>your_ossrh_password</password>
    </server>
    <server>
      <id>MyCoRe HQ</id>
      <username>your_server.mycore.de_username</username>
      <password>your_server.mycore.de_password</password>
      <configuration>
        <!- do not skip this, because the build will stuck -->
        <strictHostKeyChecking>no</strictHostKeyChecking>
      </configuration>
    </server>
  </servers>

Changes Plugin Configuration

You need to Configure the Changes Plugin in the .m2/settings.xml.

  <profile>
    <id>mail</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <changes.smtpHost>smtp.uni-jena.de</changes.smtpHost>
      <changes.mailSender.name>Sebastian Hofmann</changes.mailSender.name>
      <changes.mailSender.email>hofmann.s@uni-jena.de</changes.mailSender.email>
      <changes.startTls>true</changes.startTls>
      <changes.username>email_user</changes.username>
      <changes.password>email_password</changes.password>
      <changes.templateEncoding>UTF-8</changes.templateEncoding>
      <changes.webUser>jira_email</changes.webUser>
      <changes.webPassword>jira_token</changes.webPassword>
    </properties>
  </profile>

You can generate the token here

Before making a release of e.g. 2023.06.0:

mvn release:branch -DbranchName="2023.06.x"

You will be asked for a new SNAPSHOT version of the current (main) branch: 2013.08-SNAPSHOT After that you can push the changes of main and 2023.06.x to GitHub if you ar satisfied with the changes. You can also still modify the commits with git commit --amendand change properties of the main pom.xml but do that before the push.

Making the release

mvn release:prepare -Darguments="-Djetty"

The -Darguments="-Djetty"is just an example to tell the release plugin which maven command line arguments are needed for the correct build. Answer some questions on the next version of development and fix any SNAPSHOT dependency that may still be in the pom.xmlfiles. During this phase all changes will be made to the local repository. If all went well:

git push
git push  --tags

These steps are required for the next step:

mvn release:perform -Darguments="-Djetty"

Making the release announcement

cd target/checkout
mvn -Prelease-profile changes:announcement-generate

This steps prepares the release announcement. Check the mail body:

less target/announcement/announcement.vm

You can modify src/changes/announcement.vm and change the code name if you forgot it earlier and repeat the steps above, but if all looks ok, send it:

mvn -Prelease-profile changes:announcement-mail

Merge after the release

If you finished the release the only difference which can be merged to the master is the release commit. The release commit contains changes to the pom.xml which should not get applied to the master, so the argument -X ours should be appended to the merge command:

git checkout 2023.06.x; git pull; git checkout main; git pull; git merge --log=1000 --no-commit -X ours 2023.06.x

That's all!