Versions Compared

Old Version 11

changes.mady.by.user Unknown User (muurman)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (muurman)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

This document describes the steps you need to do when you release a product based on DS. The release protocol is described in a document in \\hafilerk\units\Deltares Software Centre\NGS\NGS-Kernteam\Projectplannen\QA\ReleaseProtocol-....doc. This list is meant as a step-by-step instruction when you want to release.

  1. Determine the version of your release. If the release has any breaking changes (_in fileformat ?) since the last release or public API) you should at least increment the minor number. So you could go from 1.1.0 to 1.2.0. See the release protocol to for details about versioning.
  2. Update the version in AssemblyInfoTemplate.cs of the DeltaShell.Core project with the version determined in 1
  3. Determine Update the project file-version of your release. If there was any change in expected.hbm.xml (DeltaShell.Plugins.Data.NHibernate.IntegrationTests) since the last release the file-version should be incrementedUse the . The project file-version to update the is defined in ProjectFileVersion of NHibernateProjectRepository.cs
  4. Update the file-version of your NetCdf files. Using the tests in NetCdfFunctionStoreVersionTest.ReadTestNetCdfFilesToCheckNoOneChangedTheDeltaShellNetCdfFileFormat you can check backward compatibility. Any new types/mappings in NetCdf should result in an increase of NetCdf file version. A change results in an increment of the DeltaShellNetCdfFileVersion in NetCdfFunctionStore.
  5. To If you want an msi that replaces your previous version (for a example a bugfix release) you should only change the product version msi name. Then you don't want to change the upgradecode GUID as this is the identifier to replace your previous version.
    If you want to create a side-by-side version you should follow the whole instruction here. Check in your changes with the message ("Release x.x.x") (x.x.x is the version of 1(example for flow)
  6. Tag/Branch your release like "Release x.x.x"Have a beer (wink)0.5 - Flow1D"
  7. Pin the externals of your release by editing the properties of the ds folder. Use -r xxx where xxx is the current revision of the DS branch. This is to prevent that externals. Something like this :svn:externals: common -r 18518 https://repos.deltares.nl/repos/ds/trunk/src/commoncommon -r 18518 https://repos.deltares.nl/repos/ds/trunk/src/common