How to release a new version
Download the deployment scripts from here and uncompress them. Then place the folder deploy_scripts into the parent folder of the folder toolbox. That is, deploy_scripts and toolbox must be siblings folders.
We assume that there exists a file ~/.m2/settings.xml containing our github credentials, if not create/modify it as follows. Make sure that previous file is not readable by everybody, so run the command chmod 700 ~/.m2/settings.xml
<settings>
<servers>
<server>
<id>github</id>
<username>[your_github_username]</username>
<password>[your_github_password]</password>
</server>
</servers>
</settings>
In addition, if we aim to deploy our artifacts signed with the private key of the AMIDST project, we should modify the ~/.m2/settings.xml file by adding a new profile:
<settings>
<profiles>
<profile>
<id>gpg</id>
<properties>
<gpg.executable>gpg2</gpg.executable>
<gpg.passphrase>[passphrase]</gpg.passphrase>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>gpg</activeProfile>
</activeProfiles>
</settings>
Go to the develop branch and verify the following points:
- Update the README.md file. In most of the cases, you will only have to change the version number.
- Update the CHANGELOG.md file by adding an entry for the new version.
- Change the AMIDST version in every pom.xml file. For that, you can simply run the following script in the deploy_scripts folder: ./replaceVersion.sh [old_version] [new_version]. For example:
./replaceVersion.sh 0.6.0 0.6.1
- In the deploy_scripts/conf/ folder, make sure that there exists a blacklist file containing all the modules or folders that will not be included in the new release. For example, for version 0.6.0, such file is called modules_blacklist-0.6.0 at its content is:
extensions/cajamar
extensions/caepia2015
extensions/ida2015
extensions/ida2016
extensions/scai2015
extensions/ecai2016
extensions/uai2016
extensions/reviewMeeting2016
extensions/nips2016
extensions/parallelVMP
doc
Afterwards, commit and push all your changes. Your local branch must be up-to-date with the remote one.
The first script startNewRelease.sh checks your local and remote configuration. If everything is ok, it will proceed to create the new version branch and to remove the unnecessary modules. For starting the new release, go to the deploy_script folder and run:
$ ./startNewRelease.sh [version]
Once the script have finished, push the new branch:
$ git push -u origin release-[version]
The second script, namely finishNewRelease.sh, will deploy the artefacts and add the tag of the new version. For that, run:
$ ./finishNewRelease.sh [version] -Dmaven.test.skip=true
where [version] must be replaced by the number of the new version (e.g., 0.6.0). The second parameter makes the process to skip the junit tests (these will be done in travis server anyway).
During the process, you will be told to merge the master branch with the one corresponding to the new release. Copy an paste the commands that appear (run them in another terminal at the folder toolbox).
Afterwards, the deployment of the maven artefacts will start. This can take several minutes. Finally the tag corresponding to the new version will be added to the corresponding commit.
Go to https://github.com/amidst/toolbox/releases where you will find and empty entry with the tag of the new release. Update the information.
For generating the JavaDoc, run
mvn clean javadoc:aggregate
The documentation files will be placed at target/site/ in a folder called apidocs. Now rename this folder with the number of the version, so you have, for instance, target/site/0.6.0/. The upload this folder to /javadoc in the webpage server. Remember to change the HTML code in index.html and latest/index.html. These folders make possible to forward to the latest version when you open http://javadoc.amidsttoolbox.com/latest/