libSBML Release procedure
This page lists the steps in our current libSBML release procedure.
Step 1: Set the date of release
The planned date of a full libsbml release allows two weeks for testing the binaries and archives that we produce. Thus for a given release a date for “code freeze” is set at two weeks prior to the anticipated release date.
- Enter dates for code freeze and release the team calendar.
- Enter date for release on Pivotal Tracker.
- Discuss at a team meeting what needs to be done in preparation for the freeze.
- Add the following Pivotal items:
- Update SBO
- Update NEWS and send for review
- Update README.md.in files if necessary
- Update version number
- Test odd configurations
- Create and test archives
- Create and test installers
Step 2: Immediately prior to code freeze
- Change the version number in VERSION.txt.
- Check whether any ErrorTables have changed and update documentation using the writeErrorTable utility.
- Update NEWS.txt with all relevant changes.
- Ensure all members of the team have read and commented on NEWS.txt as this will become the release announcement.
Once code freeze has been reached there should be no more commits of any kind to
the libsbml core and libsbml package svn repositories.
Step 3: Testing
Code then enters the testing phase, where the binaries, archives and installers are tested on a wide variety of platforms with a range of versions of different supported programming languages. Full details are available here.
Procedure when all goes well
The end of the testing period is when all the archives and installers have been created and tested.
Procedure when something goes wrong
If a problem is encountered, the following needs to be done:
- Create a pivotal story with the following characteristics:
- Outlines the problem encountered
- Identifies what needs to be changed to fix it
- Is placed above the release marker in the backlog in Pivotal Tracker
- Send an email to libsbml-team to highlight the issue as a potential release bug
The project leader (currently Sarah) then does the following:
- Reviews the problem
- Makes a decision on whether the change needs to be incorporated into the current release
If the change is to be made, then:
- The story is allocated to a developer
- The story then goes through the finish/deliver/acceptance procedure
- Additional changes to NEWS.txt are made if necessary
- Testing is restarted
- The story is moved to the pivotal backlog to be addressed in the next release
Step 4: Update software on SourceForge and PyPI
- Create a skeleton of the release folder for SF with the README files so these can be reviewed.
- Create new release number on sf.net.
- Upload the files created during testing.
- Follow the procedure for creating and uploading the documentation archives
- Upload to PyPI
Step 5: Update the copy of libSBML and the API documentation on sbml.org
Let X.Y.Z be the new version number. The name of the libSBML source directory will be
X.Y.Z after it is unpacked.
- rsync a copy of the libSBML core-plus-packages src distribution archive for X.Y.Z to
- rsync a copy of the docs distribution for X.Y.Z to
- Note it is best to rsync the archives and later use tar -zxvf filename.tar.gz on sbml.org to extract them
tar xzvf libSBML-X.Y.Z-core-plus-packages-src.tar.gz
ln -s X.Y.Z latest-stable
tar xzf ../libSBML-X.Y.Z-docs.tar.gz
- In the X.Y.Z/NEWS.txt file any special characters get mangled and need to be replaced. Currently we have several occurrences of an umlaut that need to be replaced with & o u m l ; Note chmod -R 775 on the X.Y.Z dir gives everyone permission to edit this file.
- Tidy up the
/var/www/sites/sbml/Special/Software/libSBMLdirectory to remove the
.tar.gzfiles and anything else you may have left there.
Step 5a: Other references
Step 6: Update the libSBML web pages
- Edit the following links:
- Edit Template:LibSBMLStableReleaseNumber to reflect the new release number.
- Edit Template:LibSBMLStableReleaseDate to reflect the new release date.
- Check the information at the top of libSBML page to make sure it reflects the correct release number and date, and either add or remove mention of the experimental release if necessary.
- Go to the release notes page and select edit. Change the text to refer to NEWS.txt inside the correct X.Y.Z directory for this release.
- If necessary, change downloadURL to the appropriate sourceforge directory for this release. Note: updating Template:LibSBMLStableRelease should have resulted in the correct download URL to be set, but it's good to check.
- Visit the development roadmap page:
- Edit the date and release of latest release.
- Update any text relevant to this and the next release.
- Change last release number to reflect the new release number.
- Also update the list of contributors near the bottom of the libSBML page, if appropriate.
- Update the links in the master spreadsheet for SBML Level 3 specifications.
- Do anything necessary to update examples
- Update the online validator as detailed here.
Step 7: Sourceforge housekeeping
- Tag the release in SVN
- Add a tracker group for the new libSBML release number
- Update the VERSION number so that svn code is distinguishable from release
Step 8: Announce
- Post to sbml-discuss and libsbml-development about the new release.
- Add a link to news box on sbml.org
- Post to Google+
- Tweet under the sbmlnews account
- Mail the linux developers who include libsbml