<commit_before><?xml version="1.0" encoding="UTF-8"?>
<chapter id="releases">
  <title>Releases</title>

  <para>The chapter describes the various releases and their exit criteria.</para>

  <section id="releases_overview">
    <title>Overview</title>

    <para>Each release is labelled with a version number and an identifier.</para>

    <programlisting>
ironjacamar-&lt;major&gt;.&lt;minor&gt;.&lt;patch&gt;[.&lt;identifier&gt;]
    </programlisting>

    <para>where</para>

    <itemizedlist spacing="compact">
      <listitem>
        Major: The major version number. Signifies major changes in the implementation.
      </listitem>
      <listitem>
        Minor: The minor version number. Signifies functional changes to a major version.
      </listitem>
      <listitem>
        Patch: The patch version number. Signifies a binary compatible change to a minor version.
      </listitem>
      <listitem>
        Identifier: The identifier. Identifies the level of the quality of the release.
        <itemizedlist spacing="compact">
          <listitem>
            None / Final: Stable release
          </listitem>
          <listitem>
            CR: Candidate for Release quality. The implementation is functional complete.
          </listitem>
          <listitem>
            Beta: Beta quality. The implementation is almost functional complete.
          </listitem>
          <listitem>
            Alpha: Alpha quality. The implementation is a snapshot of the development.
          </listitem>
        </itemizedlist>
      </listitem>
    </itemizedlist>

  </section>

  <section id="releases_versioning">
    <title>Versioning</title>

    <para>Each release will contain a version number which relates to the 
      feature branch where it was created.</para>

    <!-- TODO: Add a picture with versions for various branches -->

    <section id="releases_versioning_major">
      <title>Major</title>

      <para>A Major version identifier signifies major changes in the implementation such as
        a change in the architecture.</para>

      <para>The features between major versions can be a lot different, and therefore feature
        regressions may appear.</para>

      <para>A Major version will most likely also mean updates to the configuration and required
        metadata files for deployments.</para>

    </section>

    <section id="releases_versioning_minor">
      <title>Minor</title>

      <para>A Minor version identifier signifies functional changes to a Major release.</para>

      <para>This means that new features have been added to the Major release, and hence may have
        new configuration options and integration points.</para>

      <para>The release is binary compatible to the previous releases - 
        for example <code>1.0</code> vs. <code>1.1</code>.</para>

    </section>

    <section id="releases_versioning_patch">
      <title>Patch</title>

      <para>A Patch version identifier signifies a binary compatible update to one or more components in a Minor release.</para>

      <para>This means that one or more bug fixes to existing components have been integrated in the branch in question.</para>

      <para>The release is binary compatible to the previous releases - 
        for example <code>1.0.0</code> vs. <code>1.0.1</code>.</para>

    </section>

  </section>

  <section id="releases_identifiers">
    <title>Identifiers</title>
    
    <para>Each release will contain an identifier which relates to the release quality.</para>

    <!-- TODO: Add a picture with identifiers for various branches -->

    <section id="releases_alpha">
      <title>Alpha releases</title>
      
      <para>An Alpha release is a snapshot of the main development branch which likely will
        contain new features.</para>
      
      <warning>
        Alpha releases are NOT production quality
      </warning>
      
      
      <para>An Alpha release are made each month (time-boxed) unless the branch is using an identifier as 
        Beta or higher.</para>
      
      <para>The exit criteria for an Alpha release is that the main test suite is passing.</para>
      
    </section>
    
    <section id="releases_beta">
      <title>Beta releases</title>
      
      <para>A Beta release contains major features that are considered almost functional complete.
        This doesn't mean however that all aspects of each feature is complete and therefore
        not all options will be active.</para>
      
      <warning>
        Beta releases are NOT production quality
      </warning>
      
      <para>A Beta release will be made once one or more features are almost functional complete and
        therefore Beta releases aren't time-boxed, but feature-boxed instead.</para>
      
      <para>The exit criteria for a Beta release is that all test suites are passing.</para>
      
    </section>
    
    <section id="releases_cr">
      <title>Candidate for Release releases</title>

      <para>A Candidate for Release is considered functional complete and candidate for being 
        promoted to a Final release.</para>
      
      <warning>
        Candidate for Release releases are NOT production quality
      </warning>

      <para>A Candidate for Release focuses on functionality, but they are time-boxed to a maximum
        of two weeks between each release.</para>
      
      <para>The exit criteria for a Candidate for Release release is that all test suites are passing.</para>
      
    </section>
    
    <section id="releases_final">
      <title>Final releases</title>
      
      <para>A Final release is considered feature complete and stable.</para>

      <para>Typically only one Final release will be released from each branch, unless critical or blocker issues
        are found in the release. Patch releases will be available from our source control system as
        tags.</para>

      <para>The exit criteria for a Final release is that all test suites are passing.</para>
      
    </section>

  </section>


</chapter><commit_msg>Nexus deployment information<commit_after><?xml version="1.0" encoding="UTF-8"?>
<chapter id="releases">
  <title>Releases</title>

  <para>The chapter describes the various releases and their exit criteria.</para>

  <section id="releases_overview">
    <title>Overview</title>

    <para>Each release is labelled with a version number and an identifier.</para>

    <programlisting>
ironjacamar-&lt;major&gt;.&lt;minor&gt;.&lt;patch&gt;[.&lt;identifier&gt;]
    </programlisting>

    <para>where</para>

    <itemizedlist spacing="compact">
      <listitem>
        Major: The major version number. Signifies major changes in the implementation.
      </listitem>
      <listitem>
        Minor: The minor version number. Signifies functional changes to a major version.
      </listitem>
      <listitem>
        Patch: The patch version number. Signifies a binary compatible change to a minor version.
      </listitem>
      <listitem>
        Identifier: The identifier. Identifies the level of the quality of the release.
        <itemizedlist spacing="compact">
          <listitem>
            None / Final: Stable release
          </listitem>
          <listitem>
            CR: Candidate for Release quality. The implementation is functional complete.
          </listitem>
          <listitem>
            Beta: Beta quality. The implementation is almost functional complete.
          </listitem>
          <listitem>
            Alpha: Alpha quality. The implementation is a snapshot of the development.
          </listitem>
        </itemizedlist>
      </listitem>
    </itemizedlist>

  </section>

  <section id="releases_versioning">
    <title>Versioning</title>

    <para>Each release will contain a version number which relates to the 
      feature branch where it was created.</para>

    <!-- TODO: Add a picture with versions for various branches -->

    <section id="releases_versioning_major">
      <title>Major</title>

      <para>A Major version identifier signifies major changes in the implementation such as
        a change in the architecture.</para>

      <para>The features between major versions can be a lot different, and therefore feature
        regressions may appear.</para>

      <para>A Major version will most likely also mean updates to the configuration and required
        metadata files for deployments.</para>

    </section>

    <section id="releases_versioning_minor">
      <title>Minor</title>

      <para>A Minor version identifier signifies functional changes to a Major release.</para>

      <para>This means that new features have been added to the Major release, and hence may have
        new configuration options and integration points.</para>

      <para>The release is binary compatible to the previous releases - 
        for example <code>1.0</code> vs. <code>1.1</code>.</para>

    </section>

    <section id="releases_versioning_patch">
      <title>Patch</title>

      <para>A Patch version identifier signifies a binary compatible update to one or more components in a Minor release.</para>

      <para>This means that one or more bug fixes to existing components have been integrated in the branch in question.</para>

      <para>The release is binary compatible to the previous releases - 
        for example <code>1.0.0</code> vs. <code>1.0.1</code>.</para>

    </section>

  </section>

  <section id="releases_identifiers">
    <title>Identifiers</title>
    
    <para>Each release will contain an identifier which relates to the release quality.</para>

    <!-- TODO: Add a picture with identifiers for various branches -->

    <section id="releases_alpha">
      <title>Alpha releases</title>
      
      <para>An Alpha release is a snapshot of the main development branch which likely will
        contain new features.</para>
      
      <warning>
        Alpha releases are NOT production quality
      </warning>
      
      
      <para>An Alpha release are made each month (time-boxed) unless the branch is using an identifier as 
        Beta or higher.</para>
      
      <para>The exit criteria for an Alpha release is that the main test suite is passing.</para>
      
    </section>
    
    <section id="releases_beta">
      <title>Beta releases</title>
      
      <para>A Beta release contains major features that are considered almost functional complete.
        This doesn't mean however that all aspects of each feature is complete and therefore
        not all options will be active.</para>
      
      <warning>
        Beta releases are NOT production quality
      </warning>
      
      <para>A Beta release will be made once one or more features are almost functional complete and
        therefore Beta releases aren't time-boxed, but feature-boxed instead.</para>
      
      <para>The exit criteria for a Beta release is that all test suites are passing.</para>
      
    </section>
    
    <section id="releases_cr">
      <title>Candidate for Release releases</title>

      <para>A Candidate for Release is considered functional complete and candidate for being 
        promoted to a Final release.</para>
      
      <warning>
        Candidate for Release releases are NOT production quality
      </warning>

      <para>A Candidate for Release focuses on functionality, but they are time-boxed to a maximum
        of two weeks between each release.</para>
      
      <para>The exit criteria for a Candidate for Release release is that all test suites are passing.</para>
      
    </section>
    
    <section id="releases_final">
      <title>Final releases</title>
      
      <para>A Final release is considered feature complete and stable.</para>

      <para>Typically only one Final release will be released from each branch, unless critical or blocker issues
        are found in the release. Patch releases will be available from our source control system as
        tags.</para>

      <para>The exit criteria for a Final release is that all test suites are passing.</para>
      
    </section>

  </section>

  <section id="releases_nexus">
    <title>Nexus</title>

    <para>The IronJacamar artifacts are uploaded to the JBoss.org Nexus repository located at:</para>
    <programlisting>
https://repository.jboss.org/nexus/content/groups/public/
    </programlisting>

    <para>The IronJacamar artifacts are deployed under the <code>groupId</code> of:</para>
    <programlisting>
org.jboss.ironjacamar
    </programlisting>

    <para>See the User Guide for a complete list of artifacts.</para>

    <section id="releases_nexus_deploying_release">
      <title>Deploying a release</title>

      <para>A release of IronJacamar is deployed using:</para>
      <programlisting>
ant nexus
cd target
./release.sh
      </programlisting>

      <para>After the artifacts have been uploaded the release must be promoted in Nexus by logging
        in and choosing "Promote" and "Close". The path for the staging repository can be used for
        testing the release.</para>
      
      <para>Note, that this requires Ivy 2.2.0+ and Maven 2.2.1.</para>

    </section>

    <section id="releases_nexus_deploying_snapshot">
      <title>Deploying a snapshot</title>

      <para>A snapshot of IronJacamar is deployed using:</para>
      <programlisting>
ant -Dsnapshot=true nexus
cd target
./snapshot.sh
      </programlisting>
      
      <para>Note, that this requires Ivy 2.2.0+ and Maven 2.2.1.</para>

    </section>

  </section>


</chapter>
{'fraction_non_alphanumeric': 0.08390373150805917, 'fraction_numerical': 0.002796791050268639, 'mean_word_length': 2.7207009857612268, 'pattern_counts': {'":': 0, '<': 311, '<?xml version=': 2, '>': 311, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3213728', 'n_tokens_mistral': 3625, 'n_tokens_neox': 3388, 'n_words': 1405}