mirror of
https://github.com/signalwire/freeswitch.git
synced 2025-02-07 04:03:53 +00:00
85c8bcd5ed
Mon Feb 12 21:22:39 EET 2007 Maxim Zaikin <Maxim at amsd.com> * su_pthread_port.c: destroying condition variable used when destroying the thread. Tue Feb 13 01:10:38 EET 2007 kai.vehmanen@nokia.com * nua: Ignore CANCEL of incoming request if we have already sent a final response, part 2. Tue Feb 13 01:02:00 EET 2007 kai.vehmanen@nokia.com * nua: Ignore CANCEL of incoming request if we have already sent a final response. Problem reported by Mike Jerris. nua: fixed problems in state machines. Pekka Pessi <first.lastname@nokia.com>**20070214201847 These problems are mostly introduced in 1.12.5: - assert failed if INVITE was received when calling (reported by Michael Jerris) - assert failed if nua_invite() was called second time before receiving final response to first INVITE (ditto) - ACK is now always sent if session was terminated after receiving 2XX - if nua has a pending incoming INVITE request, return 491 to nua_invite() nta.c: return 481 response to CANCEL if INVITE transaction was successful According to the RFC 3261 state diagram the INVITE transaction is destroyed immediately when a final 2XX series response is sent. Now nta returns a 481 response to CANCEL if it finds an INVITE server transaction that was responded with a 2XX success response. git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@4284 d0543943-73ff-0310-b7d9-9358b9ac24b2
138 lines
4.8 KiB
Plaintext
138 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 at the sourceforge.net
|
|
shell server
|
|
|
|
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 ncftpput:
|
|
ncftpput -u anonymous -p USER@users.sourceforge.net upload.sourceforge.net /incoming/ sofia-sip-x.y.z.tar.gz
|
|
- 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.Zwork" (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.
|