Release Management Process

The Plumi Release Management Process involves the following steps:

• Ticket management (via plumi trac) & allocation to a given release
• Development assigned and commenced with active scope management to move tickets in & out of a release depending on time/funds remaining
• Code tested on a development site (eg: latest-v.plumi.org)
• Code packaged into a beta release
• Beta release deployed to demo.plumi.org for testing
• Announcements made
• Testing.engagemedia.org upgraded to beta for testing and deployment to engagemedia.org
• If required, progress through multiple beta versions & release candidates until final version is completed
• Code packaged into final
• Final deployed to demo.plumi.org
• Final announcements of the release

Making Announcements

Whenever a new version of Plumi is released, the following announcements are made:

• Blog post on blog.plumi.org with a link back to the plone.org entry (if it's a beta/RC release) or the list of new features (if it's a final release)
• Email to plumi-discuss and plumi-announce
• Update wikipedia page -  http://en.wikipedia.org/wiki/Plumi

If the release is a "final release" of a new version, the following additional steps are taken:

• Update the "Download" button on the top right hand column of blog.plumi.org to show the release number & file size (edit the sidebar.php template in WordPress?)
• Update the Download page in blog.plumi.org to reflect the new version number, the Plone version it bundles and a link to the release announcement on the plumi blog
• Update the plumi wiki start page to reflect the new version
• Attach the new version's tarball file to the plumi wiki start page (& remove the previous version's file)
• Update wikipedia page -  http://en.wikipedia.org/wiki/Plumi

Past Information

Here's the steps we followed when we were migrating EngageMedia.org to Plumi 3.