# Releasing any version of Fusiongrid codebase

This document outlines the steps needed to release Fusiongrid codebase and enable distribution - both public and private + nightly.

## 1. Mark on JIRA

<https://fusioncharts.jira.com/plugins/servlet/project-config/RED/versions>

If a version needs to be introduced:

1. Rename current target version to that
2. Add new target version of existing one and position it

Mark the version as released. Move unresolved issues to next version. _Ensure you review the unresolved issues._

Ensure that all issues in this release is "closed". Take action on unclosed issues.

## 2. Release on GIT

1. Navigate to the commit for release. Usually the head of develop or a commit on develop. Make sure remote code is pulled in.

2. Do a `git flow release` with the target version. e.g. _git flow release start 1.0.0-rc.1_ (the name should match the package.json version we are targeting.)

3. Provide release information - bump package.json and other things specific to release in this branch. Commit these changes with proper message... _bash develop/ci/bump-version/bump-version 1.0.0-rc.1 1.0.0-rc.2_ -

4. Ensure submodules are updated and run `npm test`.

5. Finish release on git flow. _git flow release finish 1.0.0-rc.2_. Additional arguments for git flow release like to keep the release branch run this _git flow release finish -k 1.0.0-rc.2_.

6. Tag the release with version number followed by `v` _v1.0.0-rc.2_. Do not delete branch or push changes yet.

7. Push the release/x, develop and master branch. Include tags. _git push origin master develop 3.4.0-rc.2_.

## 3. Packaging

1. Switch to the release tag. _git checkout 1.0.0-rc.2_
2. Make sure submodules are updated and run npm test.
3. Run _npm run-script package-release_. Thats it Dance now and check out/packages for the packages.
4. For generating checksum of the packages, Run this command _cd out; cksum packages/\* > cksum.txt;cd .._

## 4. For distributable (non-dev) releases update subsystem

The release process needs to be repeated for public tagged releases.

1. Switch to `xt-subsystem` repository.

2. Create an **action** branch with source prefix - say `action/release-edge-1.0.0-beta.2` (format - `action/<source-name>-<version-name>`.)

3. Update all source and vendor submodules to corresponding tagged releases that correspond to this. No need to update package.json for subsystem.

4. Commit the same and tag the commit with `<source-name>-<version-name>` - in this case, `edge-1.0.0-beta.2`.

### References

1. Semantic Versioning - <http://semver.org/>
2. git flow command line arguments - <https://github.com/nvie/gitflow/wiki/Command-Line-Arguments>