FOSS Project Packaging and Release

From Notes

Jump to: navigation, search

This summary follows Fogel (Chapter 7). We will be releasing the first version of the HcryptoJ software, which is hosted on Sourceforge.


Changes to HcryptoJ

  • Old bugs have been fixed (and some new bugs probably added).
  • New features have been added -- e.g., improved UI, new ways to permute alphabets.

Release Number

Since this is the first release of the software, we go with 0.5a (alpha). We will follow a two digit <major,minor> numbering system -- i.e., 0.5, 0.6, etc. Given the relatively short time period between starting this project and this release, we did not establish a separate release candidate branch in the repository.

Simple strategy: HcryptoJ will follow the strategy of changing the minor number for backward compatible changes and changing the major number of releases with substantial new features.


The code will be packaged into Java jar files. This will be done in Eclipse and uploaded to Sourceforge. In addition to the source code tree, the package will include the following supplementary files:

  • README.txt -- general information about the package, including how to compile and run the software.
  • INSTALL.txt -- instructions for unpackaging and installing the code.
  • docs -- a folder of the generated Javadoc documentation.


Given the short time period over which this release was put together, here are some things we didn't do that we probably should have done.

  • Freeze the development.
  • Set up and manage a separate release branch, distinct from the main development branch.
  • Appoint a release manager to oversee the process.
  • Thorough test the release version, fixing as many errors as possible without introducing new features.
  • Package and test the release before announcing it.
Personal tools
NSF K-12