How to Create a New Release

First thing's first… How do you increment version numbers?

This mailing list post describes the version number in detail. To summarize:

A.B.C

where

A = Major release number
    Reason for change:
      schema and/or agent API _breakage_
B = Minor release number
    Reasons for change:
      schema and/or agent APIs are _added_ or _extended_ 
      new agents added
      security fixes
      major roll up of bugfixes
C = Bugfix release number
    Reasons for change:
      any bugfix worth doing a new release/test cycl

1. Edit trunk/fossology/Makefile.conf in subversion and increment the VERSION variable to the appropriate version number based on the guidelines above.
2. Create a new tag for the release: tag the trunk/fossology/ directory and save it in /tags/<revision>/

• Create the new tagged version within subversion, tagging subversion revision NNN:

svn copy -r NNN https://fossology.svn.sourceforge.net/svnroot/fossology/trunk/fossology \
  https://fossology.svn.sourceforge.net/svnroot/fossology/tags/A.B.C

In the case where you're tagging the top of tree, you can omit the -r NNN parameter.

• You can update individual files in a tagged version if you want, but significant changes should be done on a branch instead. If you need to update individual files in the tagged version, remove the file(s) first and then replace them with:

svn delete https://fossology.svn.sourceforge.net/svnroot/fossology/tags/0.8.0/<full path to file(s)>

svn copy https://fossology.svn.sourceforge.net/svnroot/fossology/trunk/fossology/<full path to replacement file(s)> \
  https://fossology.svn.sourceforge.net/svnroot/fossology/tags/A.B.C/<full path to destination dir>

Now you should have a nice tidy directory in /tags/A.B.C/ where the released bits live. From here you can proceed to rolling a tarball and uploading the file release to sourceforge.

It is just about as easy to create a branch in svn as it is to tag. Branching creates an independent copy of one or more files in the repository, whose version history “branches” off from the point where the copy was made.

To create a new branch:

svn copy -r NNN https://fossology.svn.sourceforge.net/svnroot/fossology/trunk/fossology \
  https://fossology.svn.sourceforge.net/svnroot/fossology/branches/<your new branch name>

Please try to make the branch name descriptive, and of course make sure to include an appropriate commit message so it's clear what is being done.

The more tricky part is merging changes between branches; In the event your branch is “permanent” and not going to be merged back into the trunk, this is less of a concern (as in the case of a release branch that diverges from top of tree).

… insert merging instructions here …

To create a tarball, check out the released version. Within that directory, simply run

make tar-release

This will create a file called fossology-A.B.C.tar.gz.

Now you're ready to do a file release on Sourceforge!

Also see https://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download

• Log into http://sourceforge.net/ (using the same login/username you would use to do svn checkins).

• Go to the FOSSology project page (https://sourceforge.net/projects/fossology/), hover over the “Project Admin” tab and select “File Manager”

• Use “Create New Folder” to create a folder for the rpm & deb packages.

• Click on the gear icon to the left of the newly created folder and select “Upload here” in the pull down menu
• Upload the deb and rpm packages

• (…possible other steps)…

• You can (optionally) set properties for each of the uploads by clicking on the gear icon and selecting “Properties” in the pull down menu.

• Note there is no final “Submit” once you've updated all the fields. The file is released. You can confirm this by going to the “Download” tab in sourceforge and ensuring the file you just uploaded shows up there.

You must create a set of release notes in Dokuwiki at http://fossology.org/release_notes

Simply add the release notes to the top of the page, shifting all the previous versions down below them.

Be sure to highlight all the new features, bugfixes, any other errata.

Be sure to update the http://fossology.org/ front page with a short news blurb about the new release. You may also want to remove the oldest news blurb as well, to keep the page a bit current and up-to-date.

Finally it's important to send an announcement of the new release to the mailing list.

Email to fossology@fossology.org something like the following:

Subject:  Announcing FOSSology A.B.C Release

The FOSSology Project is pleased to announce the release of FOSSology A.B.C.

New in version A.B.C:
  * New feature
  * New feature
  * Important bug fix
  * etc... don't get too specific, but try to highlight the major changes

For more information on the FOSSology project and to download the software, 
please visit http://fossology.org/

-- About FOSSology --

FOSSology is a Free Open Source Software (FOSS) project built around an open 
and modular architecture for analyzing software. Existing modules include 
license analysis, meta data extraction, and MIME type identification. This open
source software tool analyzes a given set of software packages, and reports items 
such as the software licenses used by these packages.

More than simply reporting, “Package X uses license Y,” the FOSSology tool 
attempts to analyze every file within the package to determine its license. The 
license report is thus an aggregate of all of the different licenses found to be 
in use by a package. A single package may be labeled as “GPL” but contain files 
that use other licenses (BSD, OSL, or any of the hundreds of other licenses). Even
if an exact license is unknown, the license may be identifiable by common license 
phrases.

The FOSSology Project started as an internal software development effort within 
Hewlett Packard’s Open Source and Linux Organization. The tool evolved over 
several years at HP from a few simple shell scripts to the much more comprehensive
tool you see today.

Enjoy!
The FOSSology team

After making a release, increment the version number in trunk/fossology/Makefile.conf in subversion. Increment the least-significant digit by 1, and add ”~svn” to it (tilde svn).

For example if the release you just completed was “0.17.0”, update Makefile.conf in subversion to be version ”0.17.1~svn”. Why? So that future checkouts of HEAD will not advertise being the previous release, which they certainly are not.