Release Process - Tag, Package and Test the Release

A major constituent of the release is the "source code". This is a collection of JavaScript, Java, HTML, CSS, build script, example, and unit test files that are tracked using the Infusion source code repository. The main tasks to create a release of the source code are to tag the current revisions of the source files, and to bundle them into an archive (e.g., a zip file).

Tag, Package, Post and Announce

Tag the Source Code

Note that the Infusion 4 release is used as an example in what follows. If you are using these instructions for another release, remember to substitute the correct version number for occurrences of "4.0".

The steps to tag the source code are:

  1. Impose a source code repository freeze until the source code is tagged. Announce the freeze on the fluid-work mailing list (
    • Users are prohibited from pushing to the main project repository while the tagging operation is under way.
  2. Modify the release information in the necessary files, if this hasn't already been done:
    1. Edit the node package.json file
    2. Set the the version as appropriate, for example:

          version: "4.0.0"
    3. Ensure that the dependencies in json dependency files are up-to-date:
      • The dependencies lists must include all of the file that are to be included in the bundle.
      • The order of occurrence of the files in each list must take into account any dependencies between the files.
    4. Commit these changes and push them to the project repository.
  3. Ensure you are working with an updated clean copy of master from the project repository
    • Execute:

      # using a fresh clone
      git clone
      # or using a clean master in your current clone
      # ensure you are on master
      git checkout master
      # ensure no uncommitted changes
      git status -s
      # fetch the project-repo's (upstream) changes
      git fetch upstream
      # ensure no commits in your local master that aren't in the project-repo
      git log master ^upstream/master
      # ensure your master is up-to-date with the project-repo
      git merge upstream/master
  4. Ensure that the build works.
    1. execute:

      # create a package build of infusion
      npm run build:pkg
    2. The build will create a build directory and a products directory containing the build artifacts. Either of these can be used for testing, but the zip file in the products directory is what should be used for posting the release.
  5. Run the jqUnit tests (by opening the all-tests.html file in a browser), and ensure that all succeed.
  6. Tag the source with the release version number.
    • Execute:

      # create the tag
      git tag -a v4.0.0

Once the tag is tested and verified to be ok:

  1. Push the new tag to the public repository.
    • Execute:

      # if working a fresh clone
      git push origin v4.0.0
      # if working in an existing clone
      git push upstream v4.0.0
  2. Modify the version in the node package.json file for the main project repository to reflect that development is now for the next release version. For example:

        version: "5.0.0"
  3. Modify the fluid.version in Fluid.js.
  4. Commit the modifications and push them to the main project repository.
  5. Lift the prohibition of committing to the project repository by announcing same on the fluid-work mailing list (

Bundle the Source Code

The steps to package the source code are:

  1. With a clone from the main project repository, switch to the tag. These instructions assume the tag name is "v4.0.0"
    • Execute:

      # with a fresh clone
      git clone
      cd infusion
      git checkout v4.0.0
      # with an existing clone
      git fetch upstream
      git checkout v4.0.0
  2. Run the npm script to build the release bundles:

    # infusion-all bundle
    npm run build:pkg
    # UIO bundle 
    npm run build:pkg:custom -- -i fluid-ui-options

    This creates a folder called products and places the release bundle there; e.g.

    • This infusion-all zip file should contain the license files, as well as source, demos, examples, and tests
    • The UIO bundle will not include demos, examples and tests.
    • Each time the build is run, the previous artifacts are removed, be sure to save the zip file somewhere else before executing the next build type

Test the Release Bundles

Testing tasks for the release bundles can be found on the Release Package QA Test Plan page.

back to top