User Documentation

One minute description
Two minute tutorial
Five minute introduction
Advanced Topics
FAQ
Container
Components
Terminology
Mock Objects
Inversion of Control Types

Patterns

Inversion of Control 
Dependency Injection 
Constructor Injection 
Setter Injection 
Interface Implementation Separation 
Lifecycle 
Antipatterns

Developer Documentation

 Current build status
How To Contribute
Relative Volunteering
Release Process

Project Information

Slogan
Mailing lists
Source Repositories
Open Issues
Blog entries 
Statistics
Team
Sister Projects
TShirts

Miscellaneous

Differentiators
Nirvana

Full Sitemap

Feeds


Site
News
Release Process

The following process should be followed when a release is made. Please follow each step carefully.

  • Check that the PicoContainer Roadmap or NanoContainer Roadmap have resolved all scheduled issues. If not, resolve them, or schedule remaining issues to a future version.
  • Send email to the development mailing list telling peopl to stay away from the SCM.
  • Set the release version number in PicoContainer's project.xml. For example, 1.0-alpha-1-SNAPSHOT would become 1.0-alpha-1.
  • Update any other projects you control that depend on PicoContainer.
  • Make sure none of the external jar dependencies are SNAPSHOT dependencies, but releases or timestamped versions (so the release can be built in the future).
  • Update the Download page and add entries for the version you're about to release.
  • Update the PICO-JavaDoc Confluence shortcu (http://docs.codehaus.org/admin/browseshortcuts.action). You may have to remove the old one and add it again with an updated value.
  • Make a new java/picocontainer/site/picosite.zip (using the Teleport tool - Paul has a copy)
  • Commit your changes to the SCM.
  • Wait for DamageControl to complete a successful build (check on http://builds.codehaus.org/public/dashboard or irc://irc.codehaus.org/damagecontrol).
    • Alternatively - do maven -Dgoals=binary:deploy generic site-deploy
    • You may have to hack your Maven artifact plugin to avoid permission problems. Just delete all chmod and chgrp commands in plugin.jelly under ~/.maven/cache/maven-artifact-plugin-1.3/plugin.jelly
  • Go to the deployed site's download page and verify that the downloads work:
    • Both Ant and Maven builds for the source distros should work
    • The binary distro's docs should be browsable and links to javadocs should be local.
  • Tag the relevant CVS modules (site, pico, picoextras) via cvs -q tag RELEASE_VERSION_MODIFIER. An example release tag is PICOCONTAINER_RELEASE_1_0_ALPHA_1. (Since both PicoContainer and NanoContainer are in the same source tree, it makes sense to have a prefix).
  • Mark the version as released in JIRA: Release PicoContainer or Release NanoContainer.
  • Make sure JIRA has versions matching the version now declared in project.xml PicoContainer versions or NanoContainer versions.
  • Update the Codehaus Blog (if you have access to it) and announce the release.
  • Send email to the development mailing list announcing the release, with a link to the blog on http://blogs.codehaus.org/
  • Set the next development version number in project.xml (/project/currentVersion and /project/versions) and commit the change to the SCM. For example, 1.0-alpha-1 would become 1.0-alpha-2-SNAPSHOT.
  • If this is a major release, also send announcements to TheServerside.com, FreshMeat.net and JavaLobby.org