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 at http://d4science.web.cern.ch/d4science/ChangeLogFile/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>
Further examples: http://d4science.web.cern.ch/d4science/ChangeLogFile/changelog.xml
The file does not replace the old CHANGELOG file, that is in a human readable format and must be kept updated.
In order to include the new file inside a SA Etics configuration, developers need just to add the following command to the 'install' command of their SA 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:
- create a changelog.xml file in its component's project (or update the existing one);
- 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;
- Add as many "Change" child elements as the change/fixes/enhancements they have applied;
- 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:
- runs a dedicated script that scans all SA packages extracting all changelog.xml files, merging all of them in a uinque xml document;
- 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