Notes on making an org.lcsim release

It has been a very long time since we have made an org.lcsim/Geomconverter release. We should certainly make one soon, but since the last release various things have changed:

1. We have more developers making changes to code
2. The code seems to be in a constant state of flux, making it almost impossible to find a quiet time to make a release.
3. The code is getting more complex, and the tests are taking longer (and longer) to run.

Before/While making a release

To my mind simply saying we will make a release (say next Tuesday) will not work any longer, since things are always in flux, and there are always recent changes which have not been carefully tested. In addition to the mechanical steps involved in making a release we should.

• Review list of outstanding JIRA's (as a group). Close, Reassign, set target release etc.
• We should make sure complete nightly build is working
• Make sure all the examples are working in JAS
• Validate that tutorial documentation is still correct
• Make sure WIRED event display is working with different types of detectors, including foreign detectors
• Run some type of recon diagnostics, similar to SLICDiagnostics and validate output
• Use maven to publish release versions of jars, api's, source trees, plugins and make these accessible from our web pages.

To do this I think we will need to have a more formal release mechanism, at a minimum tag the current CVS head as a potential release, and then test that release and then if necessary create a release branch on which essential bug fixes to existing functionality should be made. This process can then proceed in parallel to development on the head.

Open Questions

• Should be split org.lcsim into more sections, for example base, recon, contrib, plugin
  • Advantages
    • makes code, tests more manageable
    • Prevents unintended dependencies, e.g. recon depending on contrib
    • We could create a separate "IntegrationTest" project into which longer running tests would be placed. This would not be routinely run by users, but could be run by the nightly build job.
  • Cons
    • Requires more training and discipline for developers
    • Changes may require updating multiple projects
• Do we need a more formal release policy
  • e.g. feature freeze, tag and branch before release
• Do we want to have different level of releases
  • Nightly build?
  • Snapshot release (monthly?)
  • Production release (3 monthly)
• Should releases be targeted to specific goals
  • E.g. release when track finding is working
  • Or release next friday at 5pm
• Do we always release from the head, or from specific tagged packages?
• We should create a package like SLIC diagnostics that produces detailed plots from the fast MC and reconstruction algorithms.