This document describes the release process for the Weld Core. We assume you are in the root directory of the Core. Before you start, take a look at the getting started guide.

We follow the JBoss Version Conventions when deciding on version numbers.

Ensure all dependencies are released

Maven is strict (which is no bad thing!) about ensuring that all dependencies are non-snapshot before starting the release. So, check the properties in pom.xml, and release any dependencies needed.

Checking whether you are good to go

The maven release plugin is very powerful, and will transform all your POMs to a release version, tag them, and then revert trunk or the branch back to a development version. We can also do a dry run to check there are no snapshot dependencies (for example, a developer might have mistakenly put the version in a sub-module). If there are any problems, you need to fix them, and check in the changes.

Make sure all the changes are checked in using git status and verify you have merged in all branches.

Now, run:

mvn release:prepare --batch-mode -Drelease -DdevelopmentVersion=A.B.C-SNAPSHOT -DreleaseVersion=X.Y.Z.Q -Dtag=X.Y.Z.Q -DdryRun

This will run through the release process, but not actually perform the tagging.

If the build fails, go back and correct the problems

Tagging the release

Now we are ready to tag the release. Make sure the tag doesn't already exist, and run:

mvn release:prepare --batch-mode -Drelease -DdevelopmentVersion=A.B.C-SNAPSHOT -DreleaseVersion=X.Y.Z.Q -Dtag=X.Y.Z.Q -Dresume=false

Once this finishes, verify that the tag is correct (e.g. use a browser).

Perform the release to maven

Now, run:

mvn release:perform nexus:staging-close -Drelease

You should see all the artifacts uploaded to the staging repository.

Building the distribution

Check out the distribution script. Now checkout the version of Weld required to co/weld.

Edit the Weld Core tag's jboss-as/pom.xml to correctly reflect the released version and weld-deployer.version to reflect the version of the JBoss AS integration which includes this version of Weld.

and run:

ant dist -Dweld.version=X.Y.Z.Q -Dweld.dir=co/weld

Note that you can also create a file named versions.properties in the dist directory that contains these properties.

QA process

The JCP bundle is normally only used for JCP final submissions.

CDI RI (Weld bundle for JCP)

• Verify readme is present
• Verify that the zip contents match those described in the readme

Upload the Weld Reference guide to docs.jboss.org

Uploading is done using SCP, SFTP, or RSYNC in a restricted secure shell on the filemgmt.jboss.org machine:

rsync -r --protocol=28 target/docbook/publish/ weld@filemgmt.jboss.org:docs_htdocs/weld/reference/{X.Y.Z.Q}

Remember to update the latest symlink

sftp weld@filemgmt.jboss.org:docs_htdocs/weld
rm reference/latest
ln -s reference/X.Y.Z.Q reference/latest

Release the project in JIRA

Don't forget to release the project in JIRA by going to the Admin page for the project, opening up the version and selecting the Release link. If there are any open issues, JIRA will ask you if you want to move them.

Promote the staging repositories

Promote any staging repositories on repository.jboss.org

Upload the QA'd bundle to SourceForge

We provide zip distributions of Weld on SourceForge, in the JBoss project. To upload the distribution, you need to have the XXX role. If you don't have this, contact Mark Newton via the Red Hat Helpdesk who can grant you the permission.

Then open the SourceForge Upload page, go to the Weld folder, and create a folder for the version, and upload the zip. You'll need to wait up to an hour while SourceForge replicates the file. Check back to the main file download page to see if the file is available.

Update SeamFramework.org and Announce

You need to update both Weld Distribution Downloads and Weld Documentation with the relevant links (copy and paste a new row from the table).

Once the documentation is available, the release is in the JBoss Maven repository, QA (if any) is complete, and the zip is available from SourceForge, you need to write a blog describing the release. Don't forget to explain what the project is, what the primary aspects of the release are, who contributed and whats coming in the future.

Once bits are live, notify the DeltaSpike team so that they can update their CI environment accordingly.