1.0.x release instructions

INSTRUCTIONS

One time setup

1. Make sure settings.xml has userid/pwd, see here

2. GPG setup (instructions here).

EACH TIME

Git work

1. Accept PR to merge change into 1.0.x
2. Create new branch just for Maven work
   The point is to use a separate commit than the code change

Edit version props in RI pom.xml(s)

Note at the time of this writing, for the last couple releases, the 1.0.x branch didn't bother resetting versions back to 1.0.N-SNAPSHOT between releases, since we weren't too active in between releases.

TODO: write some more instructions to cover this case next time we go through it.

Strategy

• We will always increment parent POM version.
• For each of API, impl (SPI+container), we will only increment the version if there has been a change

Notes:

• To release you must use a concrete, (non-snapshot) version of all modules, whether you are releasing a change in them, or not.
• If an "interim" version is needed in Maven central for testing purposes (e.g. from within Glassfish), then past convention was to use something like 1.0.3-b01 (i.e. "beta 01 for planned release of next version 1.0.3")

In detail

Note: The batch.impl.version applies to both com.ibm.jbatch.container and com.ibm.jbatch.spi child modules, which is why they should be updated together.

Edit ALL pom.xml files (parent and children)

1. In the parent pom.xml

   • increment the <version>1.0.3</version> at the top (always)
   • update only the changed versions in the <properties> section: <batch.api.version>1.0.1</batch.api.version> <batch.impl.version>1.0.3</batch.impl.version> <batch.spec.version>1.0</batch.spec.version>

2. In each child pom.xml

   • update the parent <version>1.0.3</version> to reflect the incremented update above
   • update the child's own <version>1.0.3</version> only when it has changed

3. Now do a mvn clean install from the top-level to run through the tests and install locally.

Run TCK

Execute com.ibm.jbatch.tck.exec

The module to execute the TCK against the RI from maven is the com.ibm.jbatch.tck.exec submodule, as explained here.

1. Edit the top-level pom.xml (in the parent dir of com.ibm.jbatch.tck.exec) to match the updates above.

    <!-- 
         EDIT ME WHEN BUILDING A NEW VERSION 
    -->
   
    <!-- Run against latest version of RI -->
    <batch.api.version>1.0.1</batch.api.version>
    <batch.impl.version>1.0.3</batch.impl.version>
   

2. Run the 1.0.1 TCK

   • $ git checkout 1.0.x
   • $ mvn clean install
     • Expecting to see: Tests run: 155, Failures: 0, Errors: 0, Skipped: 3

3. Run the master TCK

   • $ git checkout master
   • Redo/merge changes to top-level pom.xml: <batch.api.version>1.0.1</batch.api.version> <batch.impl.version>1.0.3</batch.impl.version>
   • $ mvn clean install
     • Expecting to see: Tests run: 167, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 131.891 sec <<< FAILURE! -in TestSuite testDeciderReceivesCorrectStepExecutionsAfterSplit(com.ibm.jbatch.tck.tests.jslxml.DeciderTests) Time elapsed: 0.354 sec <<< FAILURE!
     • You can fix this by modifying DeciderTests.java, and get to 166/166 @Test(enabled=false) // DISABLE! @org.junit.Test public void testDeciderReceivesCorrectStepExecutionsAfterSplit() throws Exception {
       • To do this you only need to rebuild child modules com.ibm.jbatch.tck and com.ibm.jbatch.tck.exec, and don't need to worry about the com.ibm.jbatch.tck.dist.* modules

Deploy

Currently we use the Maven deploy plugin.

TODO: Look here since the Nexus Staging plugin seems to have some advantages, and there's other useful info here.

Note: since some of the tests have signing sensitivities, we skip tests from now on, assuming they have already passed.

1. Verify - especially useful for verifying our GPG setup (so we can sign artifacts). $ mvn clean verify -P release-sign-artifacts -DskipTests
   • Enter GPG Passphrase at prompt
2. Deploy $ mvn clean deploy -DperformRelease=true

Release

After additional required testing (not covered here), close staging repo then release. See here if reference needed.

Cleanup: release, tagging and other bookkeeping

1. tag/push tag
2. release in GitHub (just follow earlier examples), incl. updating with fix list
3. if 1.0.x was using SNAPSHOT, then update POMS back to snapshot
4. cherry-pick back to master

OPTIONAL further instructions, you can IGNORE THE REST ...

Other testing that could be done

2. look for latest changes decompile
3. run TCK
4. look at javadoc quick
5. test by deleting new version in local repo, pointing tck to remote coordinates in parent version:

SigTest

• Oracle (not IBM JDK) might be required
• TODO: API change not really covered here.

Other History

(before https://github.com/WASdev/standards.jsr352.jbatch/commit/329a56d55236ddc818e15d8965deb08e7f847dce it was:) mvn clean verify -P '!JavaSE,JavaEE,release-sign-artifacts' -DskipTests