Naming Conventions

From Gcube Wiki
Revision as of 16:36, 2 November 2015 by Gabriele.giammatteo (Talk | contribs) (Conventions applying to SVN)

Jump to: navigation, search

Conventions applying to the ETICS System

Module Names

Module names (i.e. projects, subsystems and components as defined by the ETICS datamodel) must be of the form:

[fully-qualified-project-name] 
[fully-qualified-project-name].[subsystem-name]
[fully-qualified-project-name].[subsystem-name].[component-name]

where

  • names are all lowercase
  • fully-qualified-project-name is either 'org.gcore' or 'org.gcube'
  • subsystem-name and component-name must not contain dots ('.')
  • in case a separator is needed use a dash ('-')

Examples

org.gcube
org.gcube.vo-management
org.gcube.vo-management.credential-renewal

Configuration names

Trunk/HEAD configurations have the following form. (ETICS attaches special meaning to the '.HEAD' suffix; thus the adoption of the '.trunk' suffix has been discarded)

[module-name].HEAD

Feature Branch configurations must have the form:

[module-name].branch-[feature_description]

Public configurations must have the following form.

[module-name].[version]

Private configurations names (for the limitate usage of developers) are free-format

where

  • module-name has the format specified above
  • no dot ('.') is allowed in names

Examples

org.gcube.vo-management.credential-renewal.HEAD

org.gcube.vo-management.credential-renewal.branch-shibboleth

org.gcube.vo-management.credential-renewal.1-0-5

Conventions applying to SVN

Feature branch names must have the form:

[SVN_ROOT]/private/[dev_name].[dev_surname]/[module-name].branch-[feature_description]

Maintenance Branch names must have the form

[SVN_ROOT]/branches/[module-name]/[version-of-the-minor-release]

The usage of tags is not foreseen.

Examples

[SVN_ROOT]/private/ciro.formisano/org.gcube.vo-management.credential-renewal.branch-shibboleth
[SVN_ROOT]/branches/org.gcube.vo-management.credential/1.0

Version numbers

Component releases are identified by a version number, i.e. a combination of four numbers with the following structure:

[major-number] [minor-number] [patch-number] [age]

where the individual components stand for:

  • Major enhancements: new functionality is added to a component (or the application) and the new functionality breaks the existing API contracts or changes the user interfaces. In this case a new release of the component (system) is produced with a new version number incrementing the major version.
  • Minor enhancements: new functionality is added to a component (or the system) and the new functionality doesn’t break the API contracts or change the user interfaces. In this case a new release of the component (system) is produced with a new version number incrementing the minor version.
  • Patch: no new functionality is added. The only modifications are introduced in order to fix bugs. In this case a new release of the component (system) is produced with a new version number incrementing the revision level.
  • Age: a modification of the ETICS configuration only (e.g. command, dependencies, names, etc.). No change at all in the Source Repository.

Released configurations must be enriched with the above information. In addition, version numbers are required in configuration names (here without the 'age' field) with the following syntax:

[major-number]-[minor-number]-[patch-number]

Version numbers for ETICS '.HEAD' configurations must be set to 0.0.0-0