freeswitch/libs/sofia-sip/docs/release_management.txt
Michael Jerris ecef7d5421 Sat Jul 12 10:08:06 EDT 2008 Pekka Pessi <first.last@nokia.com>
* docs/release_management.txt: updated source upload directions



git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@9263 d0543943-73ff-0310-b7d9-9358b9ac24b2
2008-08-12 17:01:15 +00:00

137 lines
4.8 KiB
Plaintext

===================================
Sofia-SIP release management README
===================================
:Author: Kai Vehmanen <kai -dot vehmanen -at- nokia -dot- com>
:Version: 20060809-12
:Formatting: reStructuredText, http://docutils.sourceforge.net/rst.html
Introduction
============
This README contains instructions for making new Sofia-SIP releases.
Links to other resources
========================
sofia-sip/README.developers
The release notes
=================
The release notes should contain the following sections:
- about Sofia-SIP
- copied verbatim from sofia-sip/README
- list of changes since last release
- maintained in sofia-sip/RELEASE
- see diff between cvs/darcs between previous and
this version
- written in freshmeat.net "Changes:" style
- notes on API/ABI interface changes
- maintained in sofia-sip/RELEASE
- all changes in public interfaces, plus other
notes that developers should be aware of
- contributors to this release
- maintained in sofia-sip/RELEASE
- also sofia-sip/AUTHORS should be updated (file
should list all persons/companies who have code/scripts/etc
copyrighted to them in the sofia-sip tree)
See the RELEASE.template file for a full list of release note
sections.
Making the release tarball
==========================
- basics: check system clock of the build host ;)
- update the version number in sofia-sip/configure.ac
- make sure the library versions are correct, and you've
frozen all library interfaces (with correct entries in
ChangeLog files), see README.developers for more information
on library versioning in general
- make sure everything that is supposed to be in the
release is in the master darcs tree
- run 'make distcheck' to verify everything is ready for
release (requires automake-1.7 or newer)
- tag repos (darcs and any slave trees) with release tag
'rel-sofia-sip-x_y_z', where x_y_z is the version number (see
README.developers):
sh> darcs tag -m"rel-sofia-sip-x_y_z"
sh> cvs tag rel-sofia-sip-x_y_z
- take a fresh checkout of the release using the release tag
sh> darcs get http://sofia-sip.org/repos/sofia-sip --tag=rel-sofia-sip-1_yy_z
- create the release tarball with "make distcheck" (make sure depcomp et
al libtool scripts are correctly created)
- calculate md5 and sha1 hashes using md5sum and sha1sum utilities,
and copy the values to the release-notes (see below)
Creating the release notes and updating the website
===================================================
- combine the sofia-sip/RELEASE contents with
the template found from sfnet_www/templates/relnotes.txt
- store the resulting release notes to
sfnet_www/relnotes/relnotes-sofia-sip-x.y.z.txt
- add explicit link to the release notes to
sfnet_www/download.html (three most recent releases,
see guidelines in the html comments)
- update sfnet_www/index.html to mention the latest
release
- commit the change to sf.net website CVS, and run the
sfnet_www/put_online.sh script
Uploading the release to sourceforge.net
========================================
- use the the 'Admin' -> 'File releases' tool for
creating a new release
- to upload the file, you can use for example rsync:
rsync -avP -e ssh sofia-sip-x.y.z.tar.gz USER@frs.sourceforge.net:uploads/
- attach the release notes (relnotes-sofia-sip-x.y.z.txt)
to the file release
Announcing releases
===================
- send an announcement mail, containing the
release notes, to sofia-sip-devel@lists.sourceforge.net
- post a news item to freshmeat.net 'sofia-sip'
project (current project owner: Kai Vehmanen)
After release
=============
- replace the RELEASE file with RELEASE.template, and
commit it to master source repository (see sofia-sip/README.developers)
- change version in configure.ac from "X.Y.Z" to
"X.Y.Zdevel" (as it is in many cases unknown what the
next version will be)
- make a "tree open for development" commit
Syncing CVS and darcs (or some other VCS)
=========================================
Some tips for synchronizing from/to different version controlled
tree.
- As CVS cannot trace file addition/move/removals, you need
to be extra careful with these. With darcs, you can use the
'darcs changes -v' command to track down all fileops since
last synchronization.
- Always tag the src-tree with "syncuser-fromvcs-to-tovcs-yearmmdd".
- Add a top-level ChangeLog entry that documents all the
changes made outside the target tree (what, who and when -
for example produced with the "darcs changes --summary"
command).
Checking API/ABI compatibility
==============================
- Use a unit test binary built against an old library,
to verify a new library version (forwards-compatibility).
- Use the 'icheck' tool (in Debian) to make comparison
between two released versions.