From 50dd36f46db83b476b4d2cbbdf62f3982ffe3e2d Mon Sep 17 00:00:00 2001 From: Tobias Brox Date: Thu, 24 Nov 2022 00:36:52 +0100 Subject: preparing for v0.14.0-release --- USER_GUIDE.md | 9 ++++++--- calendar_cli/cal.py | 2 +- calendar_cli/legacy.py | 2 +- calendar_cli/metadata.py | 2 +- tests/README | 2 +- 5 files changed, 10 insertions(+), 7 deletions(-) diff --git a/USER_GUIDE.md b/USER_GUIDE.md index 84af0d4..50a4a4f 100644 --- a/USER_GUIDE.md +++ b/USER_GUIDE.md @@ -1,8 +1,6 @@ # User guide for calendar-cli v1.0 -This document was updated 2022-10-28. The kal command is under heavy development, this document may not always be up-to-date. - -The new command kal is under development. It can already do nearly all the things calendar-cli can do. In the upcoming release 1.0 the command name will be `kal`, with `calendar-cli` retained only for backward-compatibility. +The `kal` command is under heavy development, this document may not always be up-to-date. As of 2022-11, `kal` can do nearly all the things the old command `calendar-cli` can do. In the upcoming release 1.0 one is supposed to use `kal`, with `calendar-cli` being a deprecated legacy interface retained only for backward-compatibility. ## Command structure @@ -119,3 +117,8 @@ The subcommand `print-uid` will print out an UID. It's for convenience, the sam kal select --todo --uid=1234-5678-9abc delete kal select --todo --category computer-work --start=2022-04-04 --end=2022-05-05 edit --complete ## not supported yet kal select --todo --category computer-work --overdue edit --postpone=5d ## not supported yet + +## See also + +[NEW_CLI.md](NEW_CLI.md) is a longer, but possibly less up-to-date document containing some visions of the new `kal`-command. +[NEXT_LEVEL.md](NEXT_LEVEL.md) describes some of my visions on what a good calendaring system should be capable of, and does an attempt on mapping this down to the icalendar standard. diff --git a/calendar_cli/cal.py b/calendar_cli/cal.py index 682ac1f..24dc50b 100755 --- a/calendar_cli/cal.py +++ b/calendar_cli/cal.py @@ -2,7 +2,7 @@ """https://github.com/tobixen/calendar-cli/ - high-level cli against caldav servers. -Copyright (C) 2013-2021 Tobias Brox and other contributors. +Copyright (C) 2013-2022 Tobias Brox and other contributors. See https://www.gnu.org/licenses/gpl-3.0.en.html for license information. diff --git a/calendar_cli/legacy.py b/calendar_cli/legacy.py index b7b61dc..69dd3e6 100755 --- a/calendar_cli/legacy.py +++ b/calendar_cli/legacy.py @@ -7,7 +7,7 @@ This is the legacy calendar-cli. A new interface is being built in cal.py - aka Feedback/wishes/discussions on the new cli can be held at https://github.com/tobixen/calendar-cli/issues/88 -Copyright (C) 2013-2021 Tobias Brox and other contributors. +Copyright (C) 2013-2022 Tobias Brox and other contributors. See https://www.gnu.org/licenses/gpl-3.0.en.html for license information. """ diff --git a/calendar_cli/metadata.py b/calendar_cli/metadata.py index a81437f..2f96421 100644 --- a/calendar_cli/metadata.py +++ b/calendar_cli/metadata.py @@ -1,5 +1,5 @@ metadata = { - "version": "0.14.0.dev0", + "version": "0.14.0", "author": "Tobias Brox", "author_short": "tobixen", "copyright": "Copyright 2013-2022, Tobias Brox and contributors", diff --git a/tests/README b/tests/README index a6f9605..6d78bf2 100644 --- a/tests/README +++ b/tests/README @@ -4,4 +4,4 @@ test_calendar-cli.sh will attempt to set up a radicale server and a xandikos ser The actual tests are in tests.sh. You'll have to run this one if you want to check compatibility with other calendar servers, but it requires either that the $calendar_cli environmental variable is set, or that some calendar server is configured in .config/calendar.conf. If you choose to run the tests towards some old, existing calendar, then be aware that the test code may eventually delete some historic data from 2010. -Probably we should add some standard python test code here that can be run through nose or tox, but after all this is a command line utility - hence I found it appropriate to start with functional tests written to be executed from through a shell. +Probably we should add some standard python test code here that can be run through pytest and/or tox, but after all this is a command line utility - hence I found it appropriate to start with functional tests written to be executed from through a shell. -- cgit v1.2.3