DevelopmentProcedures

Repository architecture

The Mercurial repository has just two 'official' branches: default and release. Of course, other branches may be created for various development threads.

The default branch is essentially 'trunk' - the accumulation of development activities that are intended for eventual release. This branch should be maintained in working order (all test pass).

The release branch is just used to create releases (by the procedure given below). When a release is to be made, the default branch is merged into release, version numbers are updated (on the release branch), the full release built, and the release pushed to the publication sites. The changes on release are then merged back to trunk. There should ordinarily be no conflicts when doing these merges.

If a patch is needed on a release, it should be done on a patch branch, then merged to release, built and published. The release branch should then be merged, perhaps with conflict resolution, to trunk.

Running the plug-in

To run the jSMTLIB plug-in, execute the Run Configuration names "SMT plugin".

Running tests

All the jSMTLIB tests are implemented as JUnit tests. To run them, execute the Run Configuration named "SMT tests".

There are currently no automated tests for the plug-in.

Building the library

To build an instance of the jSMTLIB.jar library, execute the External Tools Configuration named "Build SMT Release". Note that this is just a candidate build. It does not push any files to the public site, nor does it build the plug-in files.

This action will create the following files in the SMT project: jSMTLIB.jar, jSMTLIB.tar.gz

The tar.gz file contains the library, the user guide and the LICENSE.

Building and publishing a full release

Follow these steps: [Caution: this procedure still has elements specific to DRCok's environment]

• Be sure you are operating on the default branch
• Be sure that all files are committed, the workspace is up to date and merged, the tests run cleanly, and the build is up to date (run a clean build if you are unsure).

• Move changes and build release:

  • Update to the release branch: hg update release
  • Merge changes from trunk: hg merge default
  • Resolve any conflicts
  • Commit merged changes: hg commit -m "Commits to release branch for version ${VERSION}"

• Edit the file SMTFeature/feature.xml:

  • Open SMTFeature/feature.xml
  • Open the 'Overview' tab
  • Increase the version number (to $VERSION)
  • Click on 'Synchronize' in the lower right.
  • Select the 'Force feature version...' option if it is not already selected.
  • Click 'Finish'
  • Save ALL files
• Rebuild the library with the new version number:
  • Run the External Tools Configuration 'Build SMT Release'
• Edit the site
  • Open SMTUpdateSite/site.xml
  • Click on the 'Site Map' tab (if it is not already selected)
  • Select the 'org.smtlib.SMT' category in the list box on the left
  • Click on 'Add Feature'
  • Scroll down and double-click the feature org.smtlib.SMTFeature (it should have the correct new version number)
  • Save the site.xml file
  • Leaving this new feature selected in the feature list box, click 'Build'
• Commit to Mercurial.
  • (Still on the release branch)
  • Commit the version changes: hg commit -m "Version ${VERSION}"
  • Tag the version: hg tag "V${VERSION}"
• Push to the public site
  • Execute the External Tool Configuration named 'Push jSMTLIB to Sourceforge'
• Back to development
  • Switch back to trunk: hg update default
  • Merge any release changes: hg merge release
  • Commit: hg commit -m "Commit merges from release branch"
  • Push to sourceforge repo: hg push