src/main/webapp/contribute/manual-release-guide.html [44:145]:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
            <p>The Apache Unomi project periodically declares and publishes releases. A release is one or more packages of the project artifact(s) that are approved for general public distribution and use. They may come with various degrees of caveat regarding their perceived quality and potential for change, such as "alpha", "beta", "stable", etc.</p>

            <p>The Unomi community treats releases with great importance. They are a public face of the project and most users interact with the project only through the releases. Releases are signed off by the entire Unomi community in a public vote.</p>

            <p>Each release is executed by a <em>Release Manager</em>, who is selected among the Unomi committers. This document describes the process that the Release Manager follows to perform a release. Any changes to this process should be discussed and adopted on the <a href="../community/index.html">dev@ mailing list</a>.</p>

            <p>Please remember that publishing software has legal consequences. This guide complements the foundation-wide <a href="https://www.apache.org/dev/release.html" target="_blank">Product Release Policy</a> and <a href="https://www.apache.org/dev/release-distribution" target="_blank">Release Distribution Policy</a>.</p>

            <h2 id="overview">Overview</h2>

            <p><img src="../assets/images/release-guide.png" alt="Apache Unomi release guide" title="Release Process" class="img-fluid" /></p>

            <p>The release process consists of several steps:</p>

            <ol>
              <li>Decide to release</li>
              <li>Prepare for the release</li>
              <li>Build a release candidate</li>
              <li>Vote on the release candidate</li>
              <li>During vote process, run validation tests</li>
              <li>If necessary, fix any issues and go back to step 3.</li>
              <li>Finalize the release</li>
              <li>Promote the release</li>
            </ol>

            <hr />

            <h2 id="decide-to-release">Decide to release</h2>

            <p>Deciding to release and selecting a Release Manager is the first step of the release process. This is a consensus-based decision of the entire community.</p>

            <p>Anybody can propose a release on the dev@ mailing list, giving a solid argument and nominating a committer as the Release Manager (including themselves). There's no formal process, no vote requirements, and no timing requirements. Any objections should be resolved by consensus before starting the release.</p>

            <p>In general, the community prefers to have a rotating set of 3-5 Release Managers. Keeping a small core set of managers allows enough people to build expertise in this area and improve processes over time, without Release Managers needing to re-learn the processes for each release. That said, if you are a committer interested in serving the community in this way, please reach out to the community on the dev@ mailing list.</p>

            <p>Basically we will be following the procedure described <a href="https://www.apache.org/dev/publishing-maven-artifacts.html" target="_blank">here</a> with a few more steps and details before and after.</p>


            <h3 id="checklist-to-proceed-to-the-next-step">Checklist to proceed to the next step</h3>

            <ol>
              <li>Community agrees to release</li>
              <li>Community selects a Release Manager</li>
            </ol>

            <hr />

            <h2 id="prepare-for-the-release">Prepare for the release</h2>

              <h3 id="prepare-source">Pre-flight checks</h3>
              <ol>
                  <li>Make sure all copyright years have been changed in NOTICE and any other file</li>
                  <li>Check that all SNAPSHOT versions are correct by searching for SNAPSHOT in all XML files</li>
              </ol>

              <h3 id="prepare-gpg">GPG Key configuration</h3>
              <ol>
                  <li>
                      Make sure to have a PGP key for your @apache.org email.
                      if not you can create a new one locally:
                      <pre class="alert alert-primary"><code>gpg --gen-key</code></pre>
                  </li>
                  <li>Make sure that your default GPG key is configured to use an signature with an @apache.org email.
                      You can do this by adding the following to your ~/.gnupg/gpg.conf :
                      <pre class="alert alert-primary"><code>default-key &lt;key-uid&gt;</code></pre>
                      replacing &lt;key-uid&gt; with the key uid you want to use by default. You can get the &lt;key-uid&gt; using:
                      <pre class="alert alert-primary"><code>gpg --list-secret-keys</code></pre>
                      You should then check by signing a file and verifying its signature that you have the right
                      default key:
                      <pre class="alert alert-primary"><code>gpg -ab test.txt
gpg --verify test.txt.asc test.txt
                      </code></pre>
                      This should tell you which key was used and display the email address.
                  </li>
                  <li>
                      Make sure your public KEY is available in this files (if not add your key to the files and commit/push):
                      <ol>
                          <li><a href="https://github.com/apache/unomi/blob/master/KEYS">GIT https://github.com/apache/unomi/blob/master/KEYS (cherry-pick to the branches if necessary)</a></li>
                          <li><a href="https://dist.apache.org/repos/dist/dev/unomi/KEYS">SVN https://dist.apache.org/repos/dist/dev/unomi/KEYS</a></li>
                          <li><a href="https://dist.apache.org/repos/dist/release/unomi/KEYS">SVN https://dist.apache.org/repos/dist/release/unomi/KEYS</a></li>
                      </ol>
                  </li>
                  <li>
                      Make sure your public KEY is also available in public pgp server like <a href="https://keys.openpgp.org/">https://keys.openpgp.org/</a>.
                      You can export your key to file with:
                      <pre class="alert alert-primary"><code>gpg --export USERNAME@apache.org > USERNAME@apache.pub</code></pre>
                      Then upload it on <a href="https://keys.openpgp.org/upload">https://keys.openpgp.org/upload</a>
                  </li>
              </ol>

            <h3 id="prepare-jira">Jira</h3>
            <ol>
              <li>Setup new version in JIRA project</li>
              <li>
                  Update all JIRAs, close the ones that are still not closed, review tickets that can be closed, postpone to another release tickets that are not managed now.
                  You can use this JIRA page: <a href="https://issues.apache.org/jira/projects/UNOMI?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased">Unomi JIRA releases</a>.
                  Then review the list of tickets that need to be updated, also additionally you can check the list of commits since previous release and insure they are closed using fix version: ${next.stable.version}.
                  Ideally all tickets listed for version: ${next.stable.version} should be closed or moved to the next version in case they are not finished/started.
              </li>
                <li>
                    Then you can also generate a release notes automatically using: <a href="https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12319220&version=12350150">JIRA release note</a>,
                    By choosing the version: ${next.stable.version}. It will be useful for linking the release notes in the voting mail.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



src/main/webapp/contribute/release-guide.html [44:145]:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
            <p>The Apache Unomi project periodically declares and publishes releases. A release is one or more packages of the project artifact(s) that are approved for general public distribution and use. They may come with various degrees of caveat regarding their perceived quality and potential for change, such as "alpha", "beta", "stable", etc.</p>

            <p>The Unomi community treats releases with great importance. They are a public face of the project and most users interact with the project only through the releases. Releases are signed off by the entire Unomi community in a public vote.</p>

            <p>Each release is executed by a <em>Release Manager</em>, who is selected among the Unomi committers. This document describes the process that the Release Manager follows to perform a release. Any changes to this process should be discussed and adopted on the <a href="../community/index.html">dev@ mailing list</a>.</p>

            <p>Please remember that publishing software has legal consequences. This guide complements the foundation-wide <a href="https://www.apache.org/dev/release.html" target="_blank">Product Release Policy</a> and <a href="https://www.apache.org/dev/release-distribution" target="_blank">Release Distribution Policy</a>.</p>

            <h2 id="overview">Overview</h2>

            <p><img src="../assets/images/release-guide.png" alt="Apache Unomi release guide" title="Release Process" class="img-fluid" /></p>

            <p>The release process consists of several steps:</p>

            <ol>
              <li>Decide to release</li>
              <li>Prepare for the release</li>
              <li>Build a release candidate</li>
              <li>Vote on the release candidate</li>
              <li>During vote process, run validation tests</li>
              <li>If necessary, fix any issues and go back to step 3.</li>
              <li>Finalize the release</li>
              <li>Promote the release</li>
            </ol>

            <hr />

            <h2 id="decide-to-release">Decide to release</h2>

            <p>Deciding to release and selecting a Release Manager is the first step of the release process. This is a consensus-based decision of the entire community.</p>

            <p>Anybody can propose a release on the dev@ mailing list, giving a solid argument and nominating a committer as the Release Manager (including themselves). There's no formal process, no vote requirements, and no timing requirements. Any objections should be resolved by consensus before starting the release.</p>

            <p>In general, the community prefers to have a rotating set of 3-5 Release Managers. Keeping a small core set of managers allows enough people to build expertise in this area and improve processes over time, without Release Managers needing to re-learn the processes for each release. That said, if you are a committer interested in serving the community in this way, please reach out to the community on the dev@ mailing list.</p>

            <p>Basically we will be following the procedure described <a href="https://www.apache.org/dev/publishing-maven-artifacts.html" target="_blank">here</a> with a few more steps and details before and after.</p>


            <h3 id="checklist-to-proceed-to-the-next-step">Checklist to proceed to the next step</h3>

            <ol>
              <li>Community agrees to release</li>
              <li>Community selects a Release Manager</li>
            </ol>

            <hr />

            <h2 id="prepare-for-the-release">Prepare for the release</h2>

              <h3 id="prepare-source">Pre-flight checks</h3>
              <ol>
                  <li>Make sure all copyright years have been changed in NOTICE and any other file</li>
                  <li>Check that all SNAPSHOT versions are correct by searching for SNAPSHOT in all XML files</li>
              </ol>

              <h3 id="prepare-gpg">GPG Key configuration</h3>
              <ol>
                  <li>
                      Make sure to have a PGP key for your @apache.org email.
                      if not you can create a new one locally:
                      <pre class="alert alert-primary"><code>gpg --gen-key</code></pre>
                  </li>
                  <li>Make sure that your default GPG key is configured to use an signature with an @apache.org email.
                      You can do this by adding the following to your ~/.gnupg/gpg.conf :
                      <pre class="alert alert-primary"><code>default-key &lt;key-uid&gt;</code></pre>
                      replacing &lt;key-uid&gt; with the key uid you want to use by default. You can get the &lt;key-uid&gt; using:
                      <pre class="alert alert-primary"><code>gpg --list-secret-keys</code></pre>
                      You should then check by signing a file and verifying its signature that you have the right
                      default key:
                      <pre class="alert alert-primary"><code>gpg -ab test.txt
gpg --verify test.txt.asc test.txt
                      </code></pre>
                      This should tell you which key was used and display the email address.
                  </li>
                  <li>
                      Make sure your public KEY is available in this files (if not add your key to the files and commit/push):
                      <ol>
                          <li><a href="https://github.com/apache/unomi/blob/master/KEYS">GIT https://github.com/apache/unomi/blob/master/KEYS (cherry-pick to the branches if necessary)</a></li>
                          <li><a href="https://dist.apache.org/repos/dist/dev/unomi/KEYS">SVN https://dist.apache.org/repos/dist/dev/unomi/KEYS</a></li>
                          <li><a href="https://dist.apache.org/repos/dist/release/unomi/KEYS">SVN https://dist.apache.org/repos/dist/release/unomi/KEYS</a></li>
                      </ol>
                  </li>
                  <li>
                      Make sure your public KEY is also available in public pgp server like <a href="https://keys.openpgp.org/">https://keys.openpgp.org/</a>.
                      You can export your key to file with:
                      <pre class="alert alert-primary"><code>gpg --export USERNAME@apache.org > USERNAME@apache.pub</code></pre>
                      Then upload it on <a href="https://keys.openpgp.org/upload">https://keys.openpgp.org/upload</a>
                  </li>
              </ol>

            <h3 id="prepare-jira">Jira</h3>
            <ol>
              <li>Setup new version in JIRA project</li>
              <li>
                  Update all JIRAs, close the ones that are still not closed, review tickets that can be closed, postpone to another release tickets that are not managed now.
                  You can use this JIRA page: <a href="https://issues.apache.org/jira/projects/UNOMI?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased">Unomi JIRA releases</a>.
                  Then review the list of tickets that need to be updated, also additionally you can check the list of commits since previous release and insure they are closed using fix version: ${next.stable.version}.
                  Ideally all tickets listed for version: ${next.stable.version} should be closed or moved to the next version in case they are not finished/started.
              </li>
                <li>
                    Then you can also generate a release notes automatically using: <a href="https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12319220&version=12350150">JIRA release note</a>,
                    By choosing the version: ${next.stable.version}. It will be useful for linking the release notes in the voting mail.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -