Changelog Generation procedure

Introduction

This procedure aims to create and publish a changelog list of all changes, fixes and new features in each gCube release. The list is compiled using a bottom-up approach: a) each developer compiles a list of changes in his/her component, the component’s change log, b) release managers merge all changelogs in the global changelog of the entire release.

Each component is request to include in its servicearchive a file called changelog.xml that describes all changes in the released version of the component following the schema given by File:Changelog.xsd

An example of changelog.xml file is:

<ReleaseNotes>
<Changeset component="org.gcube.messaging.consumer.1-2-0" date="2010-07-16">
  <Change>Extended the Monitoring Generic Resource with the possibility to specify site managers for each site domain</Change>
  <Change>Notification are now filtered over domain</Change>
  <Change>Added daily notification summary</Change>
</Changeset>
<Changeset component="org.gcube.messaging.consumer-library.1-1-2" date="2010-07-16">
  <Change>Added queries for NodeAccounting portlet</Change>
</Changeset>
</ReleaseNotes>

Please note that by convention the character - must be used to separate the version in the component name. This is mandatory because it have to match with the ETICS name of the component.

In order to include the new file inside a Etics configuration, developers need just to add the following command to the 'install' command of their Etics configuration :

cp ${<yourModule>.moduleDir}/changelog.xml ${prefix};

( <yourModule> is the etics module that contains the "changelog.xml" file, as for the old "CHANGELOG" )

Procedure

Following steps are executed by Developers when releasing a component:

1. create a changelog.xml file in its component's project (or update the existing one);
   1. Add a "Changeset" element on their changelog.xml file, by indicating as attribute "component" the Etics module name of the component they are releasing ( e.g .org.gcube.search.search-library.1-5-0) and the release date;
   2. Add as many "Change" child elements as the change/fixes/enhancements they have applied;
2. make sure that it is copied in the SA by putting a proper copy command in the ETICS Configuration, Usually: cp ${<yourModule>.moduleDir}/changelog.xml ${prefix}

Once the release has been closed, the Release Manager performs the following steps:

1. runs a dedicated script that scans all SA packages extracting all changelog.xml files, merging all of them in a uinque xml document;
2. runs an XSLT transformation on the global changelog.xml file that creates a wiki page stored on the SA3 wiki at Release_Notes_gCube.<version> (where <version> is replaced by the actual version of gCube). E.g. Release_Notes_gCube.2-4-0, Release_Notes_gCube.2-5-0