- Add drop-python2-support.patch to remove python-six dependency
  gh#python-caldav/caldav#228
- Remove python_module macro definition
- Update to 0.10.0
  ## Quick summary
  * Work on a universal search method
    * Refactoring, consolidated lots of slightly duplicated code into one
      method to rule them all
    * Support for things needed by the calendar-cli utility, like search by
      categories
  * Support for completion of recurring tasks
  * More utilities for tasks
    * Uncomplete-method ... for undoing the complete (recurrences not supported
      though)
    * get/set duration/dtstart/dtend (arguably this belongs to vobject and/or
      icalendar)
  * Other improvements:
    * picklable URLs
    * display_name convenience method
    * possible to set child/parent relationships
  * Potential bugfix: sequence number may need to be increased when saving
    something to the calendar (not backported, this may have side effects)
  ## Search method
  Calendar now has a method search.  Here is some information from the
  docstring:
  Parameters supported:
  * xml - use this search query, and ignore other filter parameters
  * comp_class - set to event, todo or journal to restrict search to this
    resource type.  Some server implementations require this to be set.
  * todo - sets comp_class to Todo, and restricts search to pending tasks,
    unless the next parameter is set ...
  * include_completed - include completed tasks
  * event - sets comp_class to event
  * text attribute search parameters: category, uid, summary, omment,
    description, location, status
  * expand - do server side expanding of recurring events/tasks
  * start, stop: do a time range search
  * filters - other kind of filters (in lxml tree format)
  * sort_keys - list of attributes to use when sorting
  not supported yet:
  * negated text match
  * attribute not set
  ## Completed tasks
  While the RFCs do support recurring tasks, they are not very clear on the
  details.  In v0.10 there are three different ways to complete a task.  The
  first one is to ignore the RRULE property and mark the task as completed.
  This is the backwards-compatibility mode - though, according to my
  understanding of a "recurring task" this is the wrong way to do it.
  The two other modes considers the task to be "interval based" is no BY-rules
  are specified in the RRULE - meaning that if a task is supposed to be done
  weekly, then a week should pass from it was completed and until one needs to
  start with it again - no matter the DTSTART of the original instance - but
  the standards may also be interpreted so that if the original task was to be
  started at a Tuesday 10:00, then all recurrences should be started at a
  Tuesday 10:00.
  Both the modes stores a copy of the completed task, for the record.  The
  "safe" mode stores the copy as a completely independent task, and modifies
  the DTSTART/DUE of the original task - so the completed task is not linked up
  to the recurring task.  (One may eventually try to make a link by
  establishing a "parent task").
  The "thisandfuture"-mode will establish the completed task as a separate
  recurrence in a recurrence set.  The non-completed task is also duplicated
  with a new DTSTART set and range set to THISANDFUTURE. As I understand the
  RFC, this is the way to handle interval-based tasks, future recurrences will
  then base their starting time on the DTSTART of the THISANDFUTURE task.  For
  fixed tasks the THISANDFUTURE recurrence is moot, so I'm considering to
  create a third mode as well.

• Files Changed
• Browse Source