Software Packaging and Releasing William Cohen NCSU CSC 591W March 24, 2008

Why Package? Make it clear what is in the software Want to have easy to install software Want to avoid the rough edges software in development version of software Code repository constantly changing

Software Release Process Create release branch Stabilize release branch Packaging Testing

Creating Release Branch Want to allow developers to continue to work Make separate branch to separate development from stabilization Tag showing what the release version is based on Usually some change in code with release number before and after tagging

Release Numbers Release number uniquely identifies version Group of digits separated by dots (“.”) Numbering: Major number, before “.”: Indicates major new features or changes Minor number, after “.” Indicates bug fixes or minor changes Linux distributions may have additional build numbers due to multiple builds (adding patches) Numbering ordered

Multiple Branches With mature projects multiple versions in use With multiple branches able to maintain multiple version concurrently

Stabilizing Release Branch Making sure that existing code works in release Not adding new features during stabilization Have some criteria saying that the release is good: New features works Old bugs fixed Ideally, little work require to stabilize the code from code repository

Source Packaging Open Source Software packages released as source code Have a tarball or zip file that contains the various pieces of source Source package Create single directory with contents Name of package should match created directory, e.g. oprofile-0.9.3.tar.gz should create a directory oprofile-0.9.3

Files in Source Packaging The source for the software COPYING/License file: Describe how the software can be copied and used Release notes describing package: New Features Fixed Bugs INSTALL file: List other packages needed to build software How to install the software README file: Information on the software Contact information NEWS file:

Testing Check that software works Do more that simple visual inspection of source Make sure that instructions are accurate Build from scratch Install resulting build Run test suites to check everything works Check build in multiple machines: 32- and 64-bit machine Little- and big-endian machines

Binary/Installable Packages For convenience some software projects produce binary or installable packages May build for some common platforms Often binary/installable packaging performed by distributions Need to make sure that source code for binary/installable package available: Original source tarball Any patches or modification of original source code

Candidate Release Put out version of source that wider audience can try out Testing on unusual machines Use in unusual situations, e.g. stress testing Use feedback to determine whether additional changes required

Security Release Only fixes security issue, no other issues Release process not as public because software already in use with security issue May use additional “.” number for release to avoid changing release numbering

Announcing Release Want people to know about the new release Places to post: Project webpage Freshmeat.net Explain what is new and what has changed Information to make sure people can check obtained correct download, MD5/SHA1 checksum

Further Reading Producing Opens Source Software by Karl Fogel