GridSite Developers

GridSite is principally being developed by Andrew McNab, Shiv Kaushal, Joseph Dada and Yibiao Li of the University of Manchester High Energy Physics Group, with funding from GridPP and PPARC. We also benefit from Web server and CVS resources provided by EU DataGrid, ESNW and LCG.

Along with the rest of GridPP, we are committed to Open Source licensing of the software we develop. Our working copies of the sources are publically available from the EGEE/JRA1 CVS, and are published under the liberal Modified BSD License.

Feedback (which is very welcome!) about the software can either be sent to the gridsite-discuss mailing list, or reported to our Bug Tracker if appropriate.

GridSite CVS and LXR

GridSite uses the EGEE-JRA1 CVS repository, which is also used for gLite. Currently, almost all the software is in one CVS module, which can be accessed via ViewCVS:

• org.gridsite.core

We also make a cross-referenced view of the current CVS HEAD available using LXR, and there are Doxygen API reference pages as part of the documentation for each release.

Automated builds

We make binary RPMs for recent versions of Scientific Linux (a rebuild of the Redhat Enterprise Linux open source packages) available in the builds area under Download.

The EGEE automatic build system also produces integration builds on the CVS HEAD and releases made for gLite. The builds are done either continuously or nightly, for versions of Scientific Linux which LCG is using or preparing to use.

Versioning Policy

GridSite follows the usual Major.Minor.Patch versioning scheme, and roughly follows the numbering scheme policy used by the Linux kernel.

Changes to the Major Version involve a significant change to the APIs or design.

Changes to the Minor Version may involve additions to the API, or a reinterpretation of semantics of the previous API, and you should read the administrator or developer release notes before upgrading.

For even number stable releases (1.0.x, 1.2.x, ...) you should be able to upgrade to a new version of the same Minor Version (eg 1.2.1 -> 1.2.2) without modifying your configuration or code. These changes will principally be bugfixes (but may occasionally involve backwards compatible extensions to the APIs.) Our intention is to branch the code at 1.2.0, 1.4.0 etc and then only make changes to the even numbered branches which are bugfixes.

For odd number development releases (1.1.x, 1.3.x, ...) new APIs may be introduced, modified or removed within the same Minor Version. These releases are intended as preparation for the next stable Minor Version. These odd numbered releases are made by tagging the CVS HEAD branch.

(As a rule of thumb, the more documentation exists for a feature in a development release, the more stable it is...)