v1.3.8 - various bugfixes

Refer to the CHANGELOG.md for a full list

v1.2.1

Bugfix for wrong passwords

Thanks to @bvanjeelharia for reporting and investigating (actually the traceback was reported already by @robinmayol in #270 but we failed to connect the dots).

Version 1.2.0

What's Changed from 1.1 to 1.2

Not much, but one bugfix, again the caldav library was not working for everyone despite lots of functional testing ...

Full Changelog: v1.1.3...v1.2.0

Cleaned out some python2-specific stuff

Pull request by @danigm in #228

Python2 has not been tested for quite some time, hence it has probably been broken since one of the 0.x-releases. I decided to officially drop support for python2 in version 1.0 - but since the release was overdue I procrastinated merging this pull request. To avoid breaking changes in v1.x, I threw in an assert instead.

New feature - custom http headers

Pull request by @JasonSanDiego in #288 (with style fixup in #291 ) allows headers parameter to the DAVClient constructor.

Rationale given in #285 :

I'm using Nextcloud and want to retrieve calendar (read only) subscriptions along with the normal read/write calendars. Nextcloud supports two ways of doing this. The easier of the two is to pass the custom HTTP header: X-NC-CalDAV-Webcal-Caching: On

Bugfix - basic auth broken for some servers

A bug was introduced in version 1.0, via #260 - the code would only work if there was a space in the WWW-Authenticate header. This works for most servers as they will challenge for credentials using a header like WWW-Authenticate: Basic realm="My CalDAV server" - however, WWW-Authenticate: Basic is fully allowed by RFC2617.

Thanks to @jdrozdnovak for debugging and reporting.

#289 - #290

v1.1.3

Full Changelog: v1.1.2...v1.1.3

v1.1.0.dev0 - continued development

What's Changed

Bugfixes, workarounds and annoyances

• Potential fix for issue #267 by @tobixen in #268
• misc bugfixes by @tobixen in #265
• rate-limiting of error messages when encountering broken ical by @tobixen in #272
• DAViCal workaround - set STATUS=NEEDS-ACTION by default by @tobixen in #263
• Remove annoying assert from icalendar_component by @tobixen in #274

Documentation

• Tweaking the examples by @tobixen in #271

New features

• Allow principle.calendar(calendar_url=...) by @tobixen in #273
• Allow checking DUE on dependent before moving DUE by @tobixen in #275
• allow conditional load by @tobixen in #276

Work on the test suite

Lots of work, by @tobixen in #264

Full Changelog: v1.0.1...v1.1.0.dev0

Version 1.0.1

Tests broke for what was tagged with 1.0.0 ... because I got interrupted while doing the last changes in the changelog!

Version 1.0

Version 1.0 at a glance

Version 1.0 is no big gamechanger compared to version 0.x. The biggest change is the commitment that there shouldn't be any breaking changes in any subsequent 1.x-releases.

I had some thoughts in #92 to introduce new API in version 1.0, but have reconsidered. For one thing SEMVER states:

• If your software is being used in production, it should probably already be 1.0.0.
• If you have a stable API on which users have come to depend, you should be 1.0.0.
• If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

All three points apply and they have done that for a long time, hence a 1.0-release is way overdue, and any API changes will have to wait for 2.0. I'm also intending that the only major breaking changes in 2.0 will be the removal of things that already is marked as deprecated in 1.0. If your library depends on caldav, put "caldav<3.0" in the requirements.

Breaking changes in v1.0

Python2 support is going away

Python2.x is now officially not supported - I've thrown in an assert that we're using python3. In version 1.1, some code for supporting python2 will be cleaned away ... unless, if anyone screams out that they would like to run the newest caldav library version on an old python version, I may reconsider.

"Floating time" breakage

Timezones are difficult! When an event is created through the "new" interface, and a datetime object without time zone is passed, version 0.x would send it over to the calendar servr without time zone information as a "floating time" - now it will be converted to UTC-time and sent to the server as such.

"Floating time" is defined at https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 and may be useful in some circumstances (like, from time to time, I'm trying to maintain a ritual "raise the flag on the boat at 08:00 local time every morning"). However, I believe that in a majority of cases the lack of time zone is unintentional and meant to be local time. In recent versions of python, dt.astimezone(utc) will assume dt is in local time and convert it to UTC, which in most cases probably is the correct thing to do.

If one intentionally wants to create events or tasks with "floating time", then one may use the ical_fragment parameter.

This may have the unfortunate side effect that some clients that aren't aware of their time zone (possibly including my calendar-cli - I will have to look into that) will show events in UTC-time rather than local time. I think the proper thing would be to either fix those clients to be timezone-aware, or even better, to always be explicit and always put the local time zone into the datetimes passed to calendar.save_event().

Major features

• Support for bearer token

Some bugfixes and workarounds

• new parent/child-code had some issues
• creating an event by sending an ical fragment had some issues
• expansion of recurring todos broke when the recurring_ical_event was upgraded from 1.x to 2.x
• len(calendar.objects()) did not work
• Some hacks that hopefully will allow to fetch information from DOCUframe
• We should

Documentation

Documentation now has sections on backward compatibility and "Schrodingers support" for old python versions.

The basic_usage_examples.py has been rewritten from scratch.

Test code and housekeeping

As always, the test suite is an evergrowing everchanging beast.

Pull requests

Almost all the work has been done through github pull requests this time - making it a lot easier to maintain the changelog. Those pull requests have gone into 1.0:

• changing date_search to search in documentation and examples by @yeshwantthota in #236
• Python 3.11 should be tested for by @azmeuk in #242
• recurring_ical_event 2.0 does not expand tasks by default by @tobixen in #243
• New features needed for calendar_cli aka plann by @tobixen in #244
• Bugfixes, documentation and misc by @tobixen in #246 #254 #255 #247
• When events/tasks/journals are created, "naive" datetime objects will be converted to UTC - #258
• More test code by @tobixen in #245 and #259
• Bearer authentication support by @azmeuk in #260

Some few fixups were done to some of the pull requests after the pull request was added to the master branch - in those cases I've just pushed it directly to the master branch.

Github issues and credits

I used to have a list of github issues that were touched by a release, and I also used to give credits to people that have contributed simply by raising issues. It's a lot of work going through all the issues, so I will skip it this time.

New Contributors

• @yeshwantthota made their first contribution in #236

Full Changelog: v0.11.0...v1.0.0

v0.11.0 - client side expansion and more

Warning

v0.10 and v0.11 does introduce some "bugfixes" and refactorings which
are supposed to be harmless and which haven't caused any breakages in
tests - but I cannot vouch for that it will not have unintended side
effects in your environment. If you're using the caldav library for
production-critical tasks, you may want to hang on for a while before
upgrading, or wait for v0.11.1. Version 0.11 contains minor changes
that may break backward compatibility (according to the SemVer
specification backward incompatible changes are allowed when doing
0.x-releases. Anyway, according to my knowledge this is the first
time a release contained things breaking backward-compatibility. The
return from the search method has changed a bit, I think I can do this
because v0.10 hasn't been out for long, hence most likely most users
will be using calendar.date_search() rather than calendar.search()
for doing timerange searches, and because the change is relatively
harmless and unlikely to break things. The return from the data
property is now enforced to be a normal string with unix linebreaks,
this is more likely to cause problems, but the previous behaviour was
unpredictable and would anyway sooner or later cause problems for
people depending on the return type to be a binary or being with
carriage returns).

Summary

• Daniele Ricci has made support for client-side expanding, intended
  for the calendar servers that supports recurrences but not
  server-side expanding.

• For expanded recurrences, the search-method will (by default)
  deliver each recurrence as a separate object (i.e. caldav.Event).
  This is slightly backward incompatible with v0.10.

• Now obj.data will always return an ordinary string with ordinary
  line breaks, while obj.wire_data will always return a byte string
  with CRLN line endings. This may break thinsg if the client
  expects a binary return, or depends on carriage returns in the
  output. While the return type of obj.data has been slightly
  unpredictable, it may still have been deterministic dependent on
  usage pattern - so the caller may have gotten some expectations
  which may now be broken.

• Bugfixes, some of the new code in v0.10 didn't handle icalendar data
  containing a timezone. Some other minor bugfixes.

v0.9.1

• Tweaks to support the DAVMail server implementation
• v0.9.0 broke for python 3.5 and lower, due to usage of fstrings. v0.9.1 has been tested with python 3.5.
• Discovery of some cases of broken support of recurring events on the server side, and logging of errors (optionally raising of errors)
• New method .close on the DAVClient object.

v0.9.0

API improvements

• It's now possible to put things into calendars without first
  creating valid ical data (just pass things like tdstart etc to the
  save_event/save_journal/save_todo methods).

• The DAVClient object can now work as a context manager

Major bugfixes

The authentication code was "fixed" in 0.8.x to work around some weird
bug in one specific calendar server, but this introduced lots of
problems for other servers. It was then rewritten in 0.9, but still
causing (regression) problems with some servers deviating slightly
from the relevant RFCs. With some help from Bjoern Kahl, Markus
Behrens and Michael Thingnes I believe it should now be quite robust.
(IMO, this work does not belong in the caldav library, ideally it
should suffice to pass username and password to the requests library).

Other things

Some other minor bugfixes and more work on the test framework