-
-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Select which kinds of components to return #101
Comments
Renaming the library feels a bit like a "nuclear option", not something one would like to do. I have no overview of the consequences of a library rename, but I guess it may be hard to find and hard to use the latest version of the library if one is already using this library. I think the default should be to return all components. |
There are several calendar servers today that supports recurring events, but not recurring tasks. Perhaps some of them are using this library. Perhaps they will magically start returning recurring tasks as well when upgrading the library. Wishful thinking, maybe :-) |
But it is nice that the library name matches what it's doing (by default), so ... no further complaints from my side :-) |
The fix is shipped in version 2.0.0. |
I had completely forgotten about this one, I suppose this explains python-caldav/caldav#241 :-) |
Maybe. You seem to fix the version of your dependencies though. |
Before v1.1.0, the library returned only events. Now, it is also returning other component types, see #97.
I am unsure if my code breaks when I update! niccokunzmann/open-web-calendar#136 (yep, not everything is TDD with me :)
I would like to propose a way to
It almost looks like we should do
But I can see that you might want them all in one place - so this might be not the right design. Renaming the library to
recurring_ical_components
might also be a nice step.@tobixen this is interesting to you.
The text was updated successfully, but these errors were encountered: