Release Process - Tag, Package and Test the Release

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 (fluid-work@fluidproject.org).
   • 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 git@github.com:fluid-project/infusion.git
     
      
     # 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 (fluid-work@fluidproject.org).

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 git@github.com:fluid-project/infusion.git
     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. infusion-all-4.0.0.zip

   • 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