2014-10-14 11:30:50 +02:00
|
|
|
Upgrading to latest
|
|
|
|
===================
|
|
|
|
This breaks federation between old and new servers due to signing of
|
|
|
|
transactions.
|
|
|
|
|
2014-09-18 12:27:52 +02:00
|
|
|
Upgrading to v0.3.0
|
2014-09-15 16:53:05 +02:00
|
|
|
===================
|
|
|
|
|
|
|
|
This registration API now closely matches the login API. This introduces a bit
|
|
|
|
more backwards and forwards between the HS and the client, but this improves
|
|
|
|
the overall flexibility of the API. You can now GET on /register to retrieve a list
|
|
|
|
of valid registration flows. Upon choosing one, they are submitted in the same
|
|
|
|
way as login, e.g::
|
|
|
|
|
|
|
|
{
|
|
|
|
type: m.login.password,
|
|
|
|
user: foo,
|
|
|
|
password: bar
|
|
|
|
}
|
|
|
|
|
|
|
|
The default HS supports 2 flows, with and without Identity Server email
|
|
|
|
authentication. Enabling captcha on the HS will add in an extra step to all
|
|
|
|
flows: ``m.login.recaptcha`` which must be completed before you can transition
|
|
|
|
to the next stage. There is a new login type: ``m.login.email.identity`` which
|
|
|
|
contains the ``threepidCreds`` key which were previously sent in the original
|
|
|
|
register request. For more information on this, see the specification.
|
|
|
|
|
2014-09-17 18:50:48 +02:00
|
|
|
Web Client
|
|
|
|
----------
|
|
|
|
|
|
|
|
The VoIP specification has changed between v0.2.0 and v0.3.0. Users should
|
|
|
|
refresh any browser tabs to get the latest web client code. Users on
|
|
|
|
v0.2.0 of the web client will not be able to call those on v0.3.0 and
|
|
|
|
vice versa.
|
|
|
|
|
2014-09-15 16:53:05 +02:00
|
|
|
|
2014-09-02 17:57:10 +02:00
|
|
|
Upgrading to v0.2.0
|
|
|
|
===================
|
|
|
|
|
2014-09-02 18:01:04 +02:00
|
|
|
The home server now requires setting up of SSL config before it can run. To
|
2014-09-02 18:06:50 +02:00
|
|
|
automatically generate default config use::
|
2014-09-02 17:57:10 +02:00
|
|
|
|
|
|
|
$ python synapse/app/homeserver.py \
|
|
|
|
--server-name machine.my.domain.name \
|
|
|
|
--bind-port 8448 \
|
|
|
|
--config-path homeserver.config \
|
|
|
|
--generate-config
|
|
|
|
|
2014-09-02 18:06:08 +02:00
|
|
|
This config can be edited if desired, for example to specify a different SSL
|
|
|
|
certificate to use. Once done you can run the home server using::
|
2014-09-02 17:57:10 +02:00
|
|
|
|
|
|
|
$ python synapse/app/homeserver.py --config-path homeserver.config
|
|
|
|
|
|
|
|
See the README.rst for more information.
|
|
|
|
|
2014-09-02 18:10:28 +02:00
|
|
|
Also note that some config options have been renamed, including:
|
|
|
|
|
2014-09-02 18:12:07 +02:00
|
|
|
- "host" to "server-name"
|
|
|
|
- "database" to "database-path"
|
|
|
|
- "port" to "bind-port" and "unsecure-port"
|
2014-09-02 17:57:10 +02:00
|
|
|
|
|
|
|
|
2014-08-22 14:52:38 +02:00
|
|
|
Upgrading to v0.0.1
|
2014-08-22 16:09:03 +02:00
|
|
|
===================
|
|
|
|
|
2014-08-22 14:52:38 +02:00
|
|
|
This release completely changes the database schema and so requires upgrading
|
|
|
|
it before starting the new version of the homeserver.
|
|
|
|
|
|
|
|
The script "database-prepare-for-0.0.1.sh" should be used to upgrade the
|
|
|
|
database. This will save all user information, such as logins and profiles,
|
|
|
|
but will otherwise purge the database. This includes messages, which
|
|
|
|
rooms the home server was a member of and room alias mappings.
|
|
|
|
|
|
|
|
Before running the command the homeserver should be first completely
|
|
|
|
shutdown. To run it, simply specify the location of the database, e.g.:
|
|
|
|
|
|
|
|
./database-prepare-for-0.0.1.sh "homeserver.db"
|
|
|
|
|
|
|
|
Once this has successfully completed it will be safe to restart the
|
|
|
|
homeserver. You may notice that the homeserver takes a few seconds longer to
|
|
|
|
restart than usual as it reinitializes the database.
|
|
|
|
|
|
|
|
On startup of the new version, users can either rejoin remote rooms using room
|
|
|
|
aliases or by being reinvited. Alternatively, if any other homeserver sends a
|
|
|
|
message to a room that the homeserver was previously in the local HS will
|
|
|
|
automatically rejoin the room.
|