Difference between revisions of "Naming Conventions"

From Gcube Wiki
Jump to: navigation, search
(Conventions applying to SVN)
(Conventions applying to SVN)
 
(4 intermediate revisions by the same user not shown)
Line 49: Line 49:
 
</pre>  
 
</pre>  
 
Maintenance Branch names must have the form
 
Maintenance Branch names must have the form
<pre>[SVN_ROOT]/branches/[module-name].release-[version-of-the-original-release]
+
<pre>[SVN_ROOT]/branches/[subystem-name]/[module-name]/[version-of-the-minor-release]
 
</pre>  
 
</pre>  
The usage of tags is not foreseen.
+
The release tags have the following form:
 +
<pre>
 +
[SVN_ROOT]/tags/org.gcube.[version]
 +
</pre>
 +
Each release tags contains the code of all components released organized by subsystem:
 +
<pre>
 +
[SVN_ROOT]/tags/org.gcube.[version]/[subystem-name]/[module-name]/[version-of-the-minor-release]
 +
</pre>
  
 
=== Examples ===
 
=== Examples ===
<pre>[SVN_ROOT]/branches/org.gcube.vo-management.credential-renewal.branch-shibboleth
+
<pre>
[SVN_ROOT]/branches/org.gcube.release-1-0-0
+
[SVN_ROOT]/private/ciro.formisano/org.gcube.vo-management.credential-renewal.branch-shibboleth
 +
[SVN_ROOT]/branches/org.gcube.vo-management/org.gcube.vo-management.credential-renewal/1.0
 +
[SVN_ROOT]/tags/org.gcube.3-6-0
 +
[SVN_ROOT]/tags/org.gcube.3-6-0/org.gcube.vo-management/org.gcube.vo-management.credential-renewal/1.0
 
</pre>
 
</pre>
  
Line 74: Line 84:
 
</pre>  
 
</pre>  
 
Version numbers for ETICS '.HEAD' configurations must be set to 0.0.0-0
 
Version numbers for ETICS '.HEAD' configurations must be set to 0.0.0-0
 
'''Note''': contrary to the consolidated usage of version numbers in the DILIGENT Project, D4Science policy is to have version numbers progressing independently for each component; thus reflecting the real changes applied to each component.
 

Latest revision as of 16:42, 2 November 2015

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/[subystem-name]/[module-name]/[version-of-the-minor-release]

The release tags have the following form:

[SVN_ROOT]/tags/org.gcube.[version]

Each release tags contains the code of all components released organized by subsystem:

[SVN_ROOT]/tags/org.gcube.[version]/[subystem-name]/[module-name]/[version-of-the-minor-release]

Examples

[SVN_ROOT]/private/ciro.formisano/org.gcube.vo-management.credential-renewal.branch-shibboleth
[SVN_ROOT]/branches/org.gcube.vo-management/org.gcube.vo-management.credential-renewal/1.0
[SVN_ROOT]/tags/org.gcube.3-6-0
[SVN_ROOT]/tags/org.gcube.3-6-0/org.gcube.vo-management/org.gcube.vo-management.credential-renewal/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