Hello!
I would like to try something new. So far, a release was done like
this:
1. Tag the source code.
2. Run it through the automatic testing, which also produces
binary
packages and source .tar.gz.
3. Check results.
4. Push to "experimental" repo, install, do some manual tests.
5. If all okay, push to "stable" repo (for stable releases) resp.
"unstable" (for pre-releases) and announce the new release.
6. If not okay, fix issues and restart from step 1.
The downside here is that new stable releases, like the upcoming 1.4.1
release, get little real world testing before being rolled out to all
users of the stable release branch (aka "stable" repo).
To avoid that, I'd like to introduce an intermediate step after 4 and
before 5 where I push the upcoming stable release update to "unstable",
announce it here on the list and/or in specific bugs that users might
be
watching, and only once the release has seen some testing move it to
the
"stable" repo with a formal, more widely distributed announcement. If
user testing finds regressions, the version will be superseded with a
fixed version.
This only makes sense if there really are users who are willing to pull
from "unstable" and provide feedback. Any volunteers?
Then update today from unstable and try out 1.4.1...
Changes in that release are:
SyncEvolution 1.4 -> 1.4.1, 31.03.2014
======================================
The first bug fix release in the 1.4 series addresses some issues which
occurred on some systems.
Details:
* EDS: only load one backend plugin of each kind
SyncEvolution was meant to load the syncecal or syncebook shared
object
which uses the most recent libraries (libical, libecal/libebook) on
the system and then stop loooking for alternatives. Due to a string
handling bug the check for already backends always found nothing,
leading to multiple conflicting backends loaded on some systems (for
example, those with libical0 and libical1 installed).
If that happened, the backend became unusable.
* ical: workaround for libical 1.0 builtin timezone change
libical 1.0 started to return VTIMEZONE definitions with multiple
absolute transition times instead of RRULEs. This causes problems
when
exchanging data with peers (see
https://sourceforge.net/p/freeassociation/bugs/95/).
In SyncEvolution, this affected sending an event using New Zealand
time in vCalendar 1.0 format to a phone, because the internal,
out-dated definition of the time zone in libsynthesis was used as
fallback when loading RRULE-based timezone definitions from libical
failed (see "[SyncEvolution] Some events showing wrong time on
phone"). It might also affect exchanging data with CalDAV peers (not
tested).
The workaround is to include the original code from libical.
* dbus-session.sh: create XDG_RUNTIME_DIR
More recent distros (for example, Ubuntu Saucy) rely on
XDG_RUNTIME_DIR. Each time dbus-session.sh runs, it must
ensure that the runtime dir exists and is empty.
This was a problem when trying to run activesyncd + SyncEvolution
on a headless Ubuntu Saucy server (see FDO #76273).
* Akonadi: support KDE Notes, enhanced "database" check
The KDE Notes resources store items under a different MIME type than
the one
used in AKonadi (see "[Kde-pim] note format"). SyncEvolution use the
same type
as Akonadi and thus did not find existing KDE Notes resources.
To support both while KDE and Akonadi transition to the same type,
SyncEvolution now looks for notes resources using both MIME types and
accepts
both kinds of items when reading. When writing, SyncEvolution picks
the MIME
type that is supported by the resource, which hopefully avoids
confusing the
KDE app using the resource (untested).
As a positive side effect, the "database" value used for opening a
resource is
now checked more thoroughly. Non-existent resources and the type
mismatches
like pointing a "kde-contacts" backend to a calendar resource are now
detected
early.
* Akonadi: ensure that UID is set (FDO #74342)
Akonadi resources do not enforce iCalendar 2.0 semantic like
"each VEVENT must have a UID" (see "[Kde-pim] iCalendar semantic").
When receiving an event from a peer which itself does not enforce
that semantic (Funambol, vCalendar 1.0 based phones), then we
need to generate a UID, otherwise KOrganizer will ignore the
imported event.
* Akonadi: avoid threading problem in HTTP server mode (FDO #75672)
When used as storage in a server, Akonadi got called in a background
thread
that gets created to handle slow initialization of sources and
preventing
ensuing timeouts in HTTP clients (probably not needed for Akonadi
itself,
but may still be useful when combining it with other sources).
Akonadi cannot be used like that, leading to false "Akonadi not
running"
errors or (if one got past that check) failing item operations.
* autotools: Add QtCore include path to KDEPIM_CFLAGS (FDO #75670)
This fixes an issue where configure fails to find Akonadi when
test programs do not compile because QString is not found.
* Enhanced testing again: faster execution, less false negatives
under load. Re-enabled testing of Akonadi.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
