From NSDLWiki

Contents [hide] 1 NDR Release Engineering 1.1 Code Locations under Release Engineering Control 1.2 Release Structure 1.2.1 /tags 1.2.2 /branches 1.2.3 /trunk 1.2.4 Example: Repository 1.2.5 Example: Java Toolkit 1.3 Release Process 1.3.1 Release Validation Process 1.3.2 To create a new production release... 1.3.3 To update trunk with completed fixes...

NDR Release Engineering

Code Locations under Release Engineering Control

Primary Location: https://svn.nsdl.org/NCore

Subdirectory	Purpose
/extensions/expertvoices	NDR plugins for wordpress
/extensions/mediawiki	NDR plugins for mediawiki
/repository	Interactions with Fedora repository including NDR Rest API struts application, OAI processing, NDR model enforcement, NDR-Fedora code.
/services/inference
/services/oaiprovider	Addon to build a jar that can be included in an OAI classpath that can restrict criteria for including in OAI. This is used to implement the limitation by OAIvisibility property.
/toolkits/java	Code implementing wrapper for NDR Rest API in Java
/toolkits/javascript	Code implementing wrapper for NDR Rest API in JavaScript (stubs only)
/toolkit/php	Code implementing wrapper for NDR Rest API in PHP (stubs only)

Note: You can see a more detailed descriptions of all locations at NDR Code Locations.

Release Structure

Structure	Usage
/tags	Production Releases VERY STABLE - Once created it never changes. One tag subdir per major release (ex. 1.0, 2.0, etc.) One tag subdir per minor release (ex. 1.1, 1.2, 1.3, etc.) Each release includes the previous release + all maintenance since that last release + new features (all code was copied from /trunk when the release was created)
/branches	Production Quality Bug Fixes One branch subdir named maintenance-X.X per tag which represents major/minor release (ex. /toolkits/java/branches/maintenance-1.0) STABLE - Can be used for production to get all bug fixes for the related major/minor release each maintenance branch subdir includes completed stable bug fixes since the last release (in example, all fixes since /toolkits/java/tags/1.0) Under Development Bug Fixes One branch subdir per complex bug under development UNSTABLE - Debugging and repair of complex bugs occurs here when complete and stable, merged into trunk when complete and stable, merged into appropriate maintenance branch subdir Under Development New Features One subdir for each new feature under development (ex: /toolkits/java/branches/NDR-18) UNSTABLE - Development of new features occurs here and when complete is moved to trunk NDR-18 is described in NSDL Bug Tracking System under a feature with the same NDR-18 name (https://bugtracking.nsdl.org/browse/NDR-18) when complete and stable, merged into trunk
/trunk	Staging for Next Release Reasonably Stable - completed code developed under the /branches complex bug fix subdirs and new feature subdirs are merged in when stable minor bug fixes may be developed directly in /trunk next release will be copied from /trunk once development of new features and testing are complete

NOTE: All locations under release engineering have these 3 directories and follow the conventions specified for tags, branches, and trunk. There is one exception to this. /services/oaiprovider has /tags and /branches at the expected level, but /trunk is under the /addons directory, e.g. /services/oaiprovider/addons/trunk.

Example: Repository

The following uses the /NCore/repository code as an example of the release structure.

• /NCore/repository/tags - Each represents a production release.
  • 1.0 - major production release (never changes)
  • 1.1 - minor production release copied from /trunk when it contained /repository/tags/1.0 + /repository/branches/maintenance-1.0 (never changes)
  • 1.3 - minor production release copied from /trunk when it contained /repository/tags/1.1 + /repository/branches/maintenance-1.1 + /repository/branches/maintenance-1.2 (never changes)
  • 1.4 - minor production release copied from /trunk when it contained /repository/tags/1.3 + /repository/branches/maintenance-1.3 (never changes)

• /NCore/repository/branches - Each represents bug fixes and new functionality
  • maintenance-1.1 - bug fixes since /repository/tags/1.1 release
  • maintenance-1.2 - bug fixes since /repository/tags/1.2 release (doesn't exist) ???
  • maintenance-1.3 - bug fixes since /repository/tags/1.3 release
  • maintenance-1.4 - bug fixes since /repository/tags/1.4 release
  • Complex Bug Fixes -- NONE currently under development for latest release
  • New Functionality -- NONE currently under development for latest release

• /NCore/repository/trunk - Current completed work from the last production release, maintenance bug fixes, and new features.
  • has everything from /repository/tags/1.4 release
  • has /repository/branches/maintenance-1.4 bug fixes merged in
  • includes any new features that have been completed
  • There currently aren't any new features under development for the next release.
  • The trunk will become the next production release when all work for that release is complete and incorporated into trunk.

Example: Java Toolkit

The following uses the /NCore/toolkits/java code as a second example of the release structure.

• /NCore/toolkits/java/tags - Each represents a production release.
  • 1.0 - major production release (never changes)

• /NCore/toolkits/java/branches - Each represents bug fixes and new functionality
  • maintenance-1.0 - bug fixes since tags/1.0 release
  • Complex Bug Fixes -- NONE currently under development for latest release
  • New Feature: NDR-18
    • holds code for a new feature that will be part of the next release
    • has a corresponding entry in NSDL Bug Tracking system that describes the new feature: https://bugtracking.nsdl.org/browse/NDR-18
    • when this is complete, it will be merged into the trunk and this branch will be removed

• /NCore/toolkits/java/trunk
  • has everything from /toolkits/java/tags/1.0 release
  • has /toolkits/java/branches/maintenance-1.0 bug fixes merged in
  • includes any new features that have been completed
  • will have NDR-18 new feature when it is completed

Release Process

Release Validation Process

1. All bug fixes and new features are merged into /trunk.
2. Freeze /trunk - no new features allowed
3. Testing Cycle
   1. Test /trunk
   2. Fix problems
   3. Repeat
4. Once /trunk is determined to be production level quality code, create a new production release.
5. Unfreeze /trunk

To create a new production release...

1. Make note of the largest version number which is the current production version. (currentVersion) (ex. current release for repository is: 1.4)
2. Determine the new version number of this release. (newVersion)
   • for minor release: newVersion = currentVersion + .1 (ex. next minor release for repository is: 1.5)
   • for major release: newVersion = currentVersion + 1 with decimal set to 0 (ex. next major release for repository is: 2.0)
3. Copy /trunk to /tags/newVersion (ex. /tags/1.5)

svn cp https://svn.nsdl.org/NCore/repository/trunk https://svn.nsdl.org/NCore/repository/tags/newVersion -m "Production Release newVersion"

4. Copy /tags/newVersion to /branches/maintenance-newVersion (ex. /branches/maintenance-1.5)

svn cp https://svn.nsdl.org/NCore/repository/tags/newVersion https://svn.nsdl.org/NCore/repository/branches/maintenance-newVersion -m "Create maintenance branch for production release newVersion"

To update trunk with completed fixes...

Use Eclipse tool for merging various branches and tags...

• CollabNet Merge Eclipse plugin -- allows for merging between various branches and tags (under Subclipse which needs to be added first)