On dinsdag 12 april 2016 11:42:53 CEST Alex Lutay wrote:
> The point here that Kamailio checks DB table_version and doesn't start
> if the version mismatch found.
As long as table versions are backwards compatible, just use a separate
"version" table for each Kamailio version you deploy. Set the
I personally am against this 'version' table concept altogether. It just makes
life difficult for expert users without meaningfully solving the problem it
seeks to solve.
It's just an arbitrary table; what guarantees does it offer that the version of
the definition of table X corresponds to t
Alex Lutay writes:
> The point here that Kamailio checks DB table_version and doesn't start
> if the version mismatch found.
Yes, it makes sense to be able to run older version of k on newer table
versions as long as newer versions of tables are backwards compatible,
e.g., a new field has been ad
Hi,
We are heavily using Kamailio in our product Sipwise NGCP and currently
testing possibility to provide rollback for the customers with the huge
systems as the last resort functionality in case if upgrade went wrong.
We hope never use it on practice but prefer to have such possibility.
The mai
