<commit_before>Making a new ANNIS release  {#dev-release}
==========================

\warning
This is work and progress and neither finished or tested for a real release.

Unfurtunally this requires some manual work. We used to invoke the Maven Release plugin in the process, 
but the only real usefull task was the version update and we still needed to do a lot of manual work.
Thus we decided to write down the necessary steps to perform a new ANNIS release instead of
relaying to a half-working solution with the Maven Release plugin.

1. Update the licenses in the `THIRD-PARTY` folder and commit/push to master
\code{.sh}
mvn license:add-third-party
mvn license:download-licenses
\endcode
2. Make and switch to a new *local* branch for the release in git. Do not push this branch to a remote location since you may want to throw 
   it away when the testing of the temporary release unveils release critical problems.
   Normally commit the changes after each major step.
3. Update the version information
  1. Internal version information in pom.xml files
\code{.sh}
mvn release:update-versions -DautoVersionSubmodules=true
\endcode
  2. The `ANNIS_VERSION` variable in the `buildbot_scripts/copyService.sh` script file.
4. Regenerate this documentation.
\code{.sh}
cd doc/
doxygen
cd ..
\endcode
5. Build the complete project *with* tests.
\code{.sh}
mvn clean
mvn install
\endcode
6. Do manual tests.
7. Add new changelog entry. There is a helper script in the `Misc` folder to make this easier
  1. Get the GitHub Milestone id associated the release (is visible in the URL if you view the issues of the release tracking milestone).<commit_msg>also update doxygen version number<commit_after>Making a new ANNIS release  {#dev-release}
==========================

\warning
This is work and progress and neither finished or tested for a real release.

Unfurtunally this requires some manual work. We used to invoke the Maven Release plugin in the process, 
but the only real usefull task was the version update and we still needed to do a lot of manual work.
Thus we decided to write down the necessary steps to perform a new ANNIS release instead of
relaying to a half-working solution with the Maven Release plugin.

1. Update the licenses in the `THIRD-PARTY` folder and commit/push to master
\code{.sh}
mvn license:add-third-party
mvn license:download-licenses
\endcode
2. Make and switch to a new *local* branch for the release in git. Do not push this branch to a remote location since you may want to throw 
   it away when the testing of the temporary release unveils release critical problems.
   Normally commit the changes after each major step.
3. Update the version information
  1. Internal version information in pom.xml files
\code{.sh}
mvn release:update-versions -DautoVersionSubmodules=true
\endcode
  2. The `ANNIS_VERSION` variable in the `buildbot_scripts/copyService.sh` script file.
  3. The `PROJECT_NUMBER` variable in the `doc/Doxyfile` documentation descriptor file.
4. Regenerate this documentation.
\code{.sh}
cd doc/
doxygen
cd ..
\endcode
5. Build the complete project *with* tests.
\code{.sh}
mvn clean
mvn install
\endcode
6. Do manual tests.
7. Add new changelog entry. There is a helper script in the `Misc` folder to make this easier
  1. Get the GitHub Milestone id associated the release (is visible in the URL if you view the issues of the release tracking milestone).
{'fraction_non_alphanumeric': 0.0664714494875549, 'fraction_numerical': 0.006149341142020498, 'mean_word_length': 4.191489361702128, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3595667', 'n_tokens_mistral': 941, 'n_tokens_neox': 906, 'n_words': 511}