summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--NEWS698
-rw-r--r--configure.ac2
2 files changed, 699 insertions, 1 deletions
diff --git a/NEWS b/NEWS
index 2c6c1ac8..ccbbc38b 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,701 @@
+SyncEvolution 1.3.2 -> 1.4, 16.02.2014
+======================================
+
+The 1.4 relase of SyncEvolution is the first stable version with the
+in-vehicle infotainment (IVI) PIM Manager included. GENIVI Diagnostic
+Log and Trace (DLT) is also supported. For more information about this
+aspect of SyncEvolution, see the PBAP and PIM entries in the 1.3.99.x
+release notes and
+https://syncevolution.org/blogs/pohly/2013/pim-its-all-about-contacts
+
+The biggest change for normal Linux users is Google CalDAV/CardDAV
+authentication with OAuth2. These are the open protocol that Google
+currently supports and thus the recommended way of syncing with
+Google, replacing ActiveSync and SyncML (both no longer available to
+all Google customers).
+
+Support for Google CardDAV is new. Like Evolution, SyncEvolution does
+not yet support some of the advanced features of the server, in
+particular custom labels for phone numbers, emails and
+addresses. Likewise, some client properties are not supported by the
+server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not supported. Of
+ORG, only the first two components are supported. Currently,
+properties not supported by one side get lost in a full roundtrip
+sync.
+
+SyncEvolution depends on external components for OAuth2. It can be
+compiled to use gSSO [1] or GNOME Online Accounts [2]. The latter is
+enabled in binaries from syncevolution.org. GNOME Online Accounts >=
+3.10 works out of the box for CalDAV and CardDAV. 3.8 is guaranteed to
+work for CardDAV and may also work for CalDAV, if the Linux
+distribution ships a patched version (like Debian Wheezy does). If it
+does not, then GNOME Online Accounts 3.8 binary can be patched to also
+support CalDAV, see [2]. Anything older than 3.8 does not
+work. Support for Ubuntu Online Accounts is available when compiling
+from source. For setup instructions see these READMEs.
+
+[1] https://01.org/gsso and
+ http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/signon/README
+[2] http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/goa/README
+
+Binary packages of 1.4 on syncevolution.org have enhanced support for
+recent distros. They now work with EDS >= 3.6 *and* < 3.6. Distros
+with libical1 like Ubuntu Saucy are also supported.
+
+The HTTP server became better at handling message resends when the
+server is slow with processing a message. The server is able to keep a
+sync session alive while loading the initial data set by sending
+acknowledgement replies before the client times out.
+
+Some issues in CalDAV, WebDAV and SyncML were fixed.
+
+Graham R. Cobb contributed several patches for enhancing ActiveSync
+support and making it work with Exchange 2010. Guido Günther provided
+some patches addressing problems when compiling SyncEvolution for
+Maemo.
+
+
+Details:
+
+* D-Bus server: support DLT (FDO #66769)
+
+ Diagnostic Log and Trace (DLT) manages a sequence of log messages,
+ with remote controllable level of detail. SyncEvolution optionally
+ (can be chosen at compile time and again at runtime) uses DLT
+ instead of its own syncevolution-log.html files. See README-DLT.rst
+ for more information.
+
+ To use the feature, configure SyncEvolution with
+ "--enable-dbus-server=--dlt --no-syslog"
+
+* D-Bus server: fix abort when mixing auto-sync and manual operations (FDO #73562)
+
+ When enabling auto-sync for a config and then accessing or syncing the
+ config manually via the command line tool, the server would abort at
+ the time when the auto-sync was originally scheduled.
+
+* D-Bus server: accept WBXML with charset in incoming connections
+
+ A user reported via email that the Nokia 515 sends
+ 'application/vnd.syncml+wbxml; charset=UTF-8' as type of its messages
+ this tripped up the syncevo-http-server, leading to:
+
+ [ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type
+ 'application/vnd.syncml+wbxml; charset=UTF-8' not supported for starting
+ a sync
+
+* D-Bus server: command line options for controlling output and startup
+
+ The system log is used by default now. New command line options can be
+ used to change this:
+
+ -d, --duration=seconds/'unlimited' Shut down automatically
+ when idle for this duration (default 300 seconds)
+ -v, --verbosity=level Choose amount of output, 0 = no output,
+ 1 = errors, 2 = info, 3 = debug; default is 1.
+ --dbus-verbosity=level Choose amount of output via D-Bus signals, 0 = no output,
+ 1 = errors, 2 = info, 3 = debug; default is 2.
+ -o, --stdout Enable printing to stdout (result of operations)
+ and stderr (errors/info/debug).
+ -s, --no-syslog Disable printing to syslog.
+ -p, --start-pim Activate the PIM Manager (= unified address book)
+ immediately.
+
+* D-Bus: missing out parameters in D-Bus introspection XML (FDO #57292)
+
+ The problem was in the C++ D-Bus binding. If the method that gets bound
+ to D-Bus returns a value, that value was ignored in the signature:
+ int foo() => no out parameter
+
+ It works when the method was declared as having a retval:
+ void foo (int &result) => integer out parameter
+
+ This problem existed for both the libdbus and the GIO D-Bus
+ bindings. In SyncEvolution it affected methods like GetVersions().
+
+* D-Bus server: avoid progress outside of 0-100% range
+
+ For example in the new TestLocalCache.testItemDelete100, the
+ percentage value in the ProgressChanged signal become larger
+ than 100 and then revert to 100 at the end of the sync.
+
+ Seems the underlying calculation is faulty or simply inaccurate.
+ This is not fixed. Instead the result is just clipped to the valid
+ range.
+
+* sync: less verbose output, shorter runtime
+
+ For each incoming change, one INFO line with "received x[/out of y]"
+ was printed, immediately followed by another line with total counts
+ "added x, updated y, removed z". For each outgoing change, a "sent
+ x[/out of y]" was printed.
+
+ In addition, these changes were forwarded to the D-Bus server where a
+ "percent complete" was calculated and broadcasted to clients. All of
+ that caused a very high overhead for every single change, even if the
+ actual logging was off. The syncevo-dbus-server was constantly
+ consuming CPU time during a sync when it should have been mostly idle.
+
+ To avoid this overhead, the updated received/sent numbers that come
+ from the Synthesis engine are now cached and only processed when done
+ with a SyncML message or some other event happens (whatever happens
+ first).
+
+ To keep the implementation simple, the "added x, updated y, removed z"
+ information is ignored completely and no longer appears in the output.
+
+* command line: implement --create/remove-database
+
+ Creating a database is only possible with a chosen name. The UID is
+ chosen automatically by the storage. Only implemented in the EDS
+ backend.
+
+* command line: execute --export and --print-items while the source is still reading
+
+ Instead of reading all item IDs, then iterating over them, process
+ each new ID as soon as it is available. With sources that support
+ incremental reading (only the PBAP source at the moment) that provides
+ output sooner and is a bit more memory efficient.
+
+* command line: recover from slow sync with new sync modes
+
+ The error message for an unexpected slow sync still mentioned
+ the old and obsolete "refresh-from-client/server" sync modes.
+ Better mention "refresh-from-local/remote".
+
+* command line: show backend error when listing databases fails
+
+ The command line swallowed errors thrown by the backend while listing
+ databases. Instead it just showed "<backend name>: backend failed". The goal
+ was to not distract users who accidentally access a non-functional backend.
+ But the result is that operations like --configure or --print-databases could
+ fail without giving the user any hint about the root cause of the issue.
+
+ Now the error explanation in all its gory details is included.
+
+ For example, not having activesyncd running leads to:
+ INFO] eas_contact: backend failed: fetching folder list:
+ GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
+ org.meego.activesyncd was not provided by any .service files
+
+ And running activesyncd without the necessary gconf keys shows up as:
+ [INFO] eas_contact: backend failed: fetching folder list:
+ GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find
+ account [syncevolution@lists.intel.com]
+
+* password handling: fix usage of GNOME Keyring and KWallet (FDO #66110)
+
+ When clients like the GTK sync-ui stored a password, it was always
+ stored as plain text in the config.ini file by the
+ syncevo-dbus-server. The necessary code for redirecting the password
+ storage in a keyring (GNOME or KWallet) simply wasn't called in that
+ case.
+
+ The command line tool, even when using the D-Bus server to run the
+ operation, had the necessary code active and thus was not affected.
+ Now all SyncEvolution components use the same default: use safe
+ password storage if either GNOME Keyring or KWallet were enabled
+ during compilation, don't use it if not.
+
+ Fixing this revealed other problems, like not being able to store
+ certain passwords that lacked the necessary lookup criteria (like
+ syncURL and/or username). To address this, the lookup criteria where
+ extended and a new check was added to avoid accidentally removing
+ other passwords. As a result, it may be possible that SyncEvolution
+ no longer finds passwords that were stored with older versions of
+ SyncEvolution. In such a case the passwords must be set again.
+
+* GNOME: clean up keyring access and require libgnome-keyring >= 2.20
+
+ The updated error messages now always include information about the
+ password and libgnome-keyring error texts.
+
+ A workaround is used for the "Error communicating with
+ gnome-keyring-daemon" problem that started to appear fairly
+ frequently in the automated testing once the keyring was actually
+ used. The problem shows up with some additional debug messages:
+
+ Gkr: received an invalid, unencryptable, or non-utf8 secret
+ Gkr: call to daemon returned an invalid response: (null).(null)()
+
+ It seems that sometimes setting up a session with GNOME keyring
+ fails such that all further communication leads to decoding problem.
+
+ There is an internal method to reset the session, but it cannot be
+ called directly. As a workaround, fake the death of the GNOME
+ keyring daemon and thus trigger a reconnect when retrying the GNOME
+ keyring access. This is done by sending a D-Bus message, which will
+ also affect other clients of GNOME keyring, but hopefully without
+ user-visible effects.
+
+* config: enhanced password handling
+
+ It is possible to configure a plain username/password combination
+ once in SyncEvolution and then use references to it in other
+ configurations, instead of having to set (and update) the
+ credentials in different places. This is useful in particular with
+ WebDAV, where credentials had to be repeated several times (target
+ config, in each database when used as part of SyncML) or when using
+ a service which requires several configs (Google via SyncML and
+ CalDAV).
+
+ To use this, create a sync config for a normal peer or a dedicated
+ config just for the credentials, with "username/password/syncURL"
+ set. The "syncURL" must be set to something identifying the peer if
+ GNOME Keyring is used for the password storage.
+
+ Then set "username", "databaseUser" and "proxyUser" properties to
+ "id:<name of config with credentials>" and all read and write access
+ to those properties will be redirected by SyncEvolution into that
+ other configuration. This even works in the GTK UI.
+
+ For user names which contain colons, the new "user:<user name>" format
+ must be used. Strings without colons are assumed to be normal user
+ names, so most old configurations should continue to work.
+
+* signon: new backend using libgsignond-glib + libaccounts-glib
+
+ The code works with gSSO (https://01.org/gsso) and Ubuntu Online
+ Accounts.
+
+* GOA: get OAuth2 tokens out of GNOME Online Accounts
+
+ "username = goa:..." selects an account in GOA and retrieves the
+ OAuth2 token from that.
+
+* WebDAV: support OAuth2
+
+ If given an authentication configuration which can handle OAuth2,
+ then OAuth2 is used instead of plain username/password
+ authentication.
+
+* WebDAV: support Google CardDAV, break Yahoo
+
+ Google CardDAV has one peculiarity: it renames new contacts during PUT without
+ returning the new path to the client. See also
+ http://lists.calconnect.org/pipermail/caldeveloper-l/2013-July/000524.html
+
+ SyncEvolution already had a workaround for that (PROPGET on old path, extract
+ new path from response) which happened to work. This workaround was originally
+ added for Yahoo, which sometimes merges contacts into existing ones. In
+ contrast to Yahoo, Google really seems to create new items.
+
+ Without some server specific hacks, the client cannot tell what happened.
+ Because Google is currently supported and Yahoo is not, let's change the
+ hard-coded behavior to "renamed items are new".
+
+* WebDAV: started testing with owndrive.com = OwnCloud
+
+* WebDAV: avoid segfault during collection lookup
+
+ Avoid referencing pathProps->second when the set of paths that
+ PROPFINDs returns is empty. Apparently this can happen in combination
+ with Calypso.
+
+* CalDAV: more workarounds for Google CalDAV + unique IDs
+
+ Google became even more strict about checking REV. Tests which
+ reused a UID after deleting the original item started to fail sometime
+ since middle of December 2012.
+
+* CalDAV: work around Google server regression (undeclared namespace prefix in XML)
+
+ Google CalDAV for a while (December 2012 till January 2013) sent
+ invalid XML back when asked to include CardDAV properties in a
+ PROPFIND. This got rejected in the XML parser, which prevents
+ syncing calendar data:
+
+ Neon error code 1: XML parse error at line 55: undeclared namespace prefix
+
+ In the meantime Google fixed the issue in response to a bug report
+ via email. But the workaround, only asking for the properties which
+ are really needed, still makes sense and thus is kept.
+
+* WebDAV: auto-discovery fix
+
+ With Google Contact + CardDAV the auto-discovery failed after
+ finding the default address book, without reporting that result.
+
+* WebDAV: don't send Basic Auth via http proactively (FDO #57248)
+
+ Sending basic authentication headers via http is insecure. Only do
+ it proactively when the connection is encrypted and thus protects
+ the information or when the server explicitly asks for it.
+
+* file backend: sub-second mod time stamps
+
+ Change tracking in the file backend used to be based on the
+ modification time in seconds. When running many syncs quickly (as in
+ testing), that can lead to changes not being detected when they happen
+ within a second. Now the file backend also includes the sub-second part of the
+ modification time stamp, if available.
+
+ This change is relevant when upgrading SyncEvolution: most of the
+ items will be considered "updated" once during the first sync after
+ the upgrade (or a downgrade) because the revision strings get
+ calculated differently.
+
+* GTK UI: fixed two crashes - running a sync with no service selected
+ and a 64 bit pointer problem recently discovered by Tino Keitel when
+ compiling the Debian package with -fPIE.
+
+* packaging: compatible with EDS up to and including 3.10 and both
+ libical.so.0 and libical.so.1
+
+ The binary packages now contain different versions of syncecal.so
+ and syncebooks.so to cover different combinations of EDS and libical.
+
+* libical: compatibiliy mode for libical.so.0 and libical.so.1
+
+ libical 1.0 broke the ABI, leading to libical.so.1. The only relevant change
+ for SyncEvolution is the renumbering of ICAL_*_PROPERTY enum values. We can
+ adapt to that change at runtime, which allows us to compile once with
+ libical.so.0, then patch executables or use dynamic loading to run with the
+ more recent libical.so.1 if we add 1 to the known constants.
+
+* packaging: fix rpm (FDO #73347)
+
+ After installing the syncevolution.org rpm on OpenSUSE,
+ SyncEvolution was not starting because its shared libraries were not
+ found unless "ldconfig" was called manually. Now the package does
+ that automatically.
+
+* packaging: fix description
+
+ The syncevolution-bundle description of both rpm and deb
+ packagesaccidentally used the same description as
+ syncevolution-evolution.
+
+* glib: fix double-free of source tags
+
+ glib 2.39.0 (aka GNOME 3.10) as found in Ubuntu Trusty introduces
+ warnings when g_source_remove() is passed an unknown tag. SyncEvolution
+ did this in two cases: in both, the source callback returned false and thus
+ caused the source to be removed by the caller. In that case, the explicit
+ g_source_remove() is redundant and must be avoided.
+
+ Such a call is faulty and might accidentally remove a new source with the same
+ tag (unlikely though, given that tags seem to get assigned incrementally).
+
+ The only noticable effect were additional error messages with different
+ numbers:
+
+ [ERROR] GLib: Source ID 9 was not found when attempting to remove it
+
+* EDS: fix compile problem with boost and EDS > 3.36
+
+ This fixes the following problem, seen with Boost 1.53.0 on altlinux
+ when compiling for EDS >= 3.6:
+
+ /usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access<T>::type boost::shared_ptr<T>::operator[](std::ptrdiff_t) const [with T = char*; typename boost::detail::sp_array_access<T>::type = void; std::ptrdiff_t = long int]':
+ src/backends/evolution/EvolutionSyncSource.cpp:163:38: required from here
+ /usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive]
+ make[2]: *** [src/backends/evolution/src_backends_evolution_syncecal_la-EvolutionSyncSource.lo]
+
+* EDS contacts: avoid unnecessary DB writes during slow sync
+
+ Traditionally, contacts were modified shortly before writing into EDS
+ to match with Evolution expectations (must have N, only one CELL TEL,
+ VOICE flag must be set). During a slow sync, the engine compare the
+ modified contacts with the unmodified, incoming one. This led to
+ mismatches and/or merge operations which end up not changing anything
+ in the DB because the only difference would be removed again before
+ writing.
+
+* EDS contacts: read-ahead cache
+
+ Performance is improved by requesting multiple contacts at once and
+ overlapping reading with processing. On a fast system (SSD, CPU fast
+ enough to not be the limiting factor), testpim.py's testSync takes 8
+ seconds for a "match" sync where 1000 contacts get loaded and compared
+ against the same set of contacts. Read-ahead with only 1 contact per
+ query speeds that up to 6.7s due to overlapping IO and
+ processing. Read-ahead with the default 50 contacts per query takes
+ 5.5s. It does not get much faster with larger queries.
+
+* PBAP: add support for obexd 0.47, 0.48 and Bluez 5
+
+ obexd 0.48 is almost the same as obexd 0.47, except that it dropped
+ the SetFilter and SetFormat methods in favor of passing a Bluex 5-style
+ filter parameter to PullAll.
+
+* PBAP: various enhancements for efficient caching of contacts
+
+* HTTP server: handle message resends
+
+ If a client gave up waiting for the server's response and resent its message
+ while the server was still processing the message, syncing failed with
+ "protocol error: already processing a message" raised by the
+ syncevo-dbus-server because it wasn't prepared to handle that situation.
+
+ The right place to handle this is inside the syncevo-http-server, because it
+ depends on the protocol (HTTP in this case) whether resending is valid or
+ not. It handles that now by tracking the message that is currently in
+ processing and matching it against each new message. If it matches, the new
+ request replaces the obsolete one without sending the message again to
+ syncevo-dbus-server. When syncevo-dbus-server replies to the old message, the
+ reply is used to finish the newer request.
+
+* engine: prevent timeouts in HTTP server mode
+
+ HTTP SyncML clients give up after a certain timeout (SyncEvolution
+ after RetryDuration = 5 minutes by default, Nokia e51 after 15
+ minutes) when the server fails to respond.
+
+ This can happen with SyncEvolution as server when it uses a slow
+ storage with many items, for example via WebDAV. In the case of slow
+ session startup, multithreading is now used to run the storage
+ initializing in parallel to sending regular "keep-alive" SyncML
+ replies to the client.
+
+ By default, these replies are sent every 2 minutes. This can be
+ configured with another extensions of the SyncMLVersion property:
+ SyncMLVersion = REQUESTMAXTIME=5m
+
+ Other modes do not use multithreading by default, but it can be
+ enabled by setting REQUESTMAXTIME explicitly. It can be disabled
+ by setting the time to zero.
+
+ The new feature depends on a libsynthesis with multithreading enabled
+ and glib >= 2.32.0, which is necessary to make SyncEvolution itself
+ thread-safe. With an older glib, multithreading is disabled, but can
+ be enabled as a stop-gap measure by setting REQUESTMAXTIME explicitly.
+
+* Various testing and stability enhancements. SyncEvolution had to
+ be made thread-safe for the HTTP timeout prevention.
+
+* Nokia: always add TYPE=INTERNET to EMAIL (FDO #61784)
+
+ Without the explicit TYPE=INTERNET, email addresses sent to a Nokia
+ e51 were not shown by the phone and even got lost eventually (when
+ syncing back).
+
+ This commit ensures that the type is set for all emails sent to any
+ Nokia phone, because there may be other phones which need it and
+ phones which don't, shouldn't mind. This was spot-checked with a N97
+ mini, which works fine with and without the INTERNET type.
+
+ This behavior can be disabled again for specific Nokia phones by
+ adding a remote rule which sets the addInternetEmail session variable
+ to FALSE again.
+
+ Non-Nokia phones can enable the feature in a similar way, by setting
+ the variable to TRUE.
+
+* SyncML: config option for broken peers
+
+ Some peers have problems with meta data (CtCap, old Nokia phones)
+ and the sync mode extensions required for advertising the restart
+ capability (Oracle Beehive). The default in SyncEvolution is to
+ advertise the capability, so manual configuration is necessary when
+ working with a peer that fails in that mode.
+
+ Because the problem occurs when SyncEvolution contacts the peers
+ before it gets the device information from the peer, dynamic rules
+ based on the peer identifiers cannot be used. Instead the local config
+ must already disable these extra features in advance.
+
+ The "SyncMLVersion" property gets extended for this. Instead of just
+ "SyncMLVersion = 1.0" (as before) it now becomes possible to say
+ "SyncMLVersion = 1.0, noctcap, norestart".
+
+ "noctcap" disables sending CtCap. "norestart" disables the sync mode
+ extensions and thus doing multiple sync cycles in the same session
+ (used between SyncEvolution instances in some cases to get client and
+ server into sync in one session).
+
+ Both keywords are case-insensitive. There's no error checking for
+ typos, so beware!
+
+ The "SyncMLVersion" property was chosen because it was already in use
+ for configuring SyncML compatibility aspects and adding a new property
+ would have been harder.
+
+* ActiveSync: added support for specifying folder names
+
+ Previously, the database field was interpreted as a Collection ID. This adds
+ logic to allow the database to be interpreted as a folder path. The logic is:
+
+ 1) If the database is an empty string, pass it through (this is the most
+ common case as it is interpreted as "use the default folder for the
+ source type").
+ 2) If the database matches a Collection ID, use the ID (this is the same as
+ the previous behaviour).
+ 3) If the database matches a folder path name, with an optional leading "/",
+ use the Collection ID for the matching folder.
+ 4) Otherwise, force a FolderSync to get the latest folder changes from the
+ server and repeat steps 2 and 3
+ 5) If still no match, throw an error.
+
+* ActiveSync: support for listing databases
+
+ Now --print-databases scans folders on the ActiveSync server and
+ shows suitable folders for the ActiveSync backends instead of the
+ previous, hard-coded help text.
+
+ Invoking --print-databases can be used as a workaround for
+ "SyncFolder error: Invalid synchronization key" errors. A better
+ solution would be to do that automatically, but there was no time
+ to implement that. See FDO #61869 and "[SyncEvolution] Activesync server losing state"
+ http://thread.gmane.org/gmane.comp.mobile.syncevolution/4295
+
+* SyncML: workarounds for broken peers
+
+ Some peers have problems with meta data (CtCap, old Nokia phones) and
+ the sync mode extensions required for advertising the restart
+ capability (Oracle Beehive).
+
+ Because the problem occurs when SyncEvolution contacts the peers
+ before it gets the device information from the peer, dynamic rules
+ based on the peer identifiers cannot be used. Instead the local config
+ must already disable these extra features in advance.
+
+ The "SyncMLVersion" property gets extended for this. Instead of just
+ "SyncMLVersion = 1.0" (as before) it now becomes possible to say
+ "SyncMLVersion = 1.0, noctcap, norestart".
+
+ "noctcap" disables sending CtCap. "norestart" disables the sync mode
+ extensions and thus doing multiple sync cycles in the same session
+ (used between SyncEvolution instances in some cases to get client and
+ server into sync in one session).
+
+ Both keywords are case-insensitive. There's no error checking for
+ typos, so beware!
+
+ The "SyncMLVersion" property was chosen because it was already in use
+ for configuring SyncML compatibility aspects and adding a new property
+ would have been harder.
+
+* engine: local cache sync mode
+
+ This patch introduces support for true one-way syncing ("caching"):
+ the local datastore is meant to be an exact copy of the data on the
+ remote side. The assumption is that no modifications are ever made
+ locally outside of syncing. This is different from one-way sync modes,
+ which allows local changes and only temporarily disables sending them
+ to the remote side.
+
+ Another goal of the new mode is to avoid data writes as much as
+ possible.
+
+ This new mode only works on the server side of a sync, where the
+ engine has enough control over the data flow. Setting "sync" to:
+ - "local-cache-incremental" will do an incremental sync (if possible)
+ or a slow sync (otherwise). This is usually the right mode to use,
+ and thus has "local-cache" as alias.
+ - "local-cache-slow" will always do a slow sync. Useful for
+ debugging or after (accidentally) making changes on the local side.
+ An incremental sync will ignore such changes because they are not
+ meant to happen, aren't checked for to improve performance and
+ thus will leave client and server out-of-sync!
+
+ Both modes are recorded in the sync report of the local side. The
+ target side is the client and records the normal "two-way" or "slow"
+ sync modes.
+
+ With the current SyncEvolution contact field list, first, middle and
+ last name are used to find matches for contacts. For events, tasks
+ and memos, time, summary and description are used.
+
+* Minor memory leak fix when using GDBus GIO: GDBusMethodInfo
+
+ Also depends on a glib fix, see https://bugzilla.gnome.org/show_bug.cgi?id=695376
+
+* build fixes
+
+ Avoid -lrt in make dependencies. Add missing pcre libs to
+ syncevo-dbus-server. sqlite backend needs "#include <stdio.h>"
+ (patch from Mario Kicherer).
+
+* autotools: fix temp file vulnerability during compilation (CVE-2014-1639)
+
+ We must use the temporary file that was created for us securily, not
+ a temp file named after that file. This caused a temp file vulnerability
+ and the real temporary files were not deleted by the script.
+
+* workarounds for warnings from g++ 4.5
+
+
+Upgrading from releases <= 1.3.99.4:
+
+If the value of "username/databaseUser/proxyUser" contains a colon,
+the "user:" prefix must be added to the value, to continue treating it
+like a plain user name and not some reference to an unknown identity
+provider (like "id:", "goa:", "signon:", etc.).
+
+The lookup of passwords in GNOME Keyring was updated slightly in
+1.3.99.5. It may be necessary to set passwords anew if the old one is
+no longer found.
+
+Upgrading from release 1.2.x:
+
+The sync format of existing configurations for Mobical (aka Everdroid)
+must be updated manually, because the server has encoding problems when
+using vCard 3.0 (now the default for Evolution contacts):
+ syncevolution --configure \
+ syncFormat=text/x-vcard \
+ mobical addressbook
+
+The Funambol template explicitly enables usage of the
+"refresh-from-server" sync mode to avoid getting throttled with 417
+'retry later' errors. The same must be added to existing configs
+manually:
+ syncevolution --configure \
+ enableRefreshSync=TRUE \
+ funambol
+
+Upgrading from releases before 1.2:
+
+Old configurations can still be read. But writing, as it happens
+during a sync, must migrate the configuration first. Releases >= 1.2
+automatically migrates configurations. The old configurations
+will still be available (see "syncevolution --print-configs") but must
+be renamed manually to use them again under their original names with
+older SyncEvolution releases.
+
+
+SyncEvolution 1.3.99.7 -> 1.4, 16.02.2014
+=========================================
+
+Compared to the pre-release, 1.4 mostly just enhanced the testing.
+Compatibility with GNOME 3.10 and a glib-related issue that existed
+almost forever without causing obvious problems were
+fixed. syncevolution.org binaries now finally work with distros using
+libical.so.1 (for example, Ubuntu Saucy and Trusty).
+
+Details:
+
+* autotools: fix temp file vulnerability during compilation (CVE-2014-1639)
+
+ We must use the temporary file that was created for us securily, not
+ a temp file named after that file. This caused a temp file vulnerability
+ and the real temporary files were not deleted by the script.
+
+* glib: fix double-free of source tags
+
+ glib 2.39.0 (aka GNOME 3.10) as found in Ubuntu Trusty introduces
+ warnings when g_source_remove() is passed an unknown tag. SyncEvolution
+ did this in two cases: in both, the source callback returned false and thus
+ caused the source to be removed by the caller. In that case, the explicit
+ g_source_remove() is redundant and must be avoided.
+
+ Such a call is faulty and might accidentally remove a new source with the same
+ tag (unlikely though, given that tags seem to get assigned incrementally).
+
+ The only noticable effect were additional error messages with different
+ numbers:
+
+ [ERROR] GLib: Source ID 9 was not found when attempting to remove it
+
+* libical: compatibiliy mode for libical.so.0 and libical.so.1
+
+ libical 1.0 broke the ABI, leading to libical.so.1. The only relevant change
+ for SyncEvolution is the renumbering of ICAL_*_PROPERTY enum values. We can
+ adapt to that change at runtime, which allows us to compile once with
+ libical.so.0, then patch executables or use dynamic loading to run with the
+ more recent libical.so.1 if we add 1 to the known constants.
+
+
SyncEvolution 1.3.99.7, 22.01.2014
==================================
diff --git a/configure.ac b/configure.ac
index 7e9b0daa..8c34d511 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ dnl Invoke autogen.sh to produce a configure script.
#
# Starting with the 1.1 release cycle, the rpm-style
# .99 pseudo-version number is used to mark a pre-release.
-AC_INIT([syncevolution], [m4_esyscmd([build/gen-git-version.sh 1.3.99.7])])
+AC_INIT([syncevolution], [m4_esyscmd([build/gen-git-version.sh 1.4])])
# STABLE_VERSION=1.0.1+
AC_SUBST(STABLE_VERSION)