Documentation -> Migration -> Migration from 3.4.x to 3.5.0

This page has been visited 605 times.

This section is meant to provide useful help in migrating your OpenSIPS installations from the 3.4.0 version to 3.5.0.

You can find the all the new additions in the 3.5.0 release compiled under this page. The ChangeLog may help your understanding of the migration / update process.

Make sure you don't carry a left-over Makefile.conf file in your OpenSIPS source tree if migrating to a new branch! This configuration file, generated by make menuconfig, is usually not compatible with the one of a previous major release!

1.  DB migration

You can migrate your 3.4.x MySQL DB to the 3.5.x format using the opensips-cli tool :

   # opensips-cli -x database migrate 3.4_to_3.5 opensips_3_4 opensips_3_5

where :

• opensips_3_4 is the existing DB name corresponding to version 3.4.x format
• opensips_3_5 is the DB name to be created for 3.5.x format

See the opensips-cli documentation for more details.

NOTE:

• the old database will not be deleted, altered or changed - it will not be touched at all
• new database will be created and data from old DB will be imported into it

Back to Table of Contents

2.  Script migration

The following is the full list of backwards-incompatible syntax or functional changes in the OpenSIPS configuration script:

• example

2.1  Global Parameters

• The mpath parameter can take several values. This means that if your script contains several declarations, and you rely on the fact that only the last one is being used, you need to completely delete (or comment) the previous ones, otherwise they will be taken into account in the modules search algorithm, and moreover, they will be prioritized.

2.2  Core Variables

• example

2.3  Core keywords

• example

2.4  Core functions

• example

2.5  Core MI commands

• example

2.6  Statistics migration

• example

3.  Module migration

3.1  AVPOPS module

• renamed into DBops module

3.2  SQL_CACHER module

• BE CAREFUL, the DOUBLE types are now returned as strings, rather than corrupted numerical values.

4.  Packaging migration