summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--USER_GUIDE.md9
-rwxr-xr-xcalendar_cli/cal.py2
-rwxr-xr-xcalendar_cli/legacy.py2
-rw-r--r--calendar_cli/metadata.py2
-rw-r--r--tests/README2
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.