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 nobrainer when you want to release.
- Determine the version of your release. If the release has any breaking changes (in fileformat 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.
- Update the version in AssemblyInfoTemplate.cs of the DeltaShell.Core project with the version determined in 1
- Determine the 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 incremented
- Determine 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.
- Use the file-version to update the ProjectFileVersion of NHibernateProjectRepository.cs
- To create a side-by-side version you should follow the whole instruction here. (example for flow)
- Check in your changes with the message ("Release x.x.x") (x.x.x is the version of 1)
- Tag/Branch your release like "Release x.x.x"
- Have a beer
