preparing for v0.14.0-release

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.