Sept 19th, 2014

A few fixes have landed in git, a little polish. Some fixes for c-c startup deadlocks that I don’t consider common enough to push another alpha release.

The good news is that with current git I haven’t experienced any crashes or bad behavior.

The bad news is that my TODO has been reduced to stuff that’s going to be tedious, but required by due diligence. Here’s my scrub list for a release:

  • Documentation (mostly man pages now that :help is supported, but also polish there getting keybind output to be more natural)
  • Along with documentation, plugins and hooks need to be audited to make sure they come from appropriate threads and hold appropriate locks
  • Tab completion polish (path completions for browser, arrow keys for history instead of C-u or whatever the weird readline default bind is)
  • c-c disconnect and (possibly) reconnect support
  • c-c feed setting query/set (this is the only bullet that will require daemon changes)
  • c-c fix or remove remaining kwarg commands (old system – I think “edit” is the only one that needs to be “ported”, the others can mostly be removed or hidden)
  • c-c fix unfiltered filtered items jumping (i.e. with filter_read set an item as read, then unread again and it may jump to the end of the feed since to the backend it’s “new”)
  • c-c hide or polish raw config settings (i.e. all of the aliases for canto-remote one-config) a lot of these are too low level and would be better used in a plugin context now that that’s a little more mature
  • c-c fetch, possibly with MIME support in plugin form
  • c-c option to shutup log.info output (mostly for autocmd plugin)

I won’t pretend this list is complete, and obviously any more serious bugs will be handled, but when this list is down to nothing, it’ll be time for 0.9.0.

After I package up an 0.9.0 release and make a post about it here, I’ll probably go on a spree of filing bugs with various distros. 0.7.x packages need to be dropped and, if there are 0.8.0 packages they need to be upgraded (so AUR packages will be marked out of date etc.). I won’t badger distros to include 0.9.x, but I will continue to automatically generate releases for Debian/Ubuntu until they’re not useful anymore.

Looking beyond 0.9.0, I imagine there will be 0.9.x maintenance releases for bugs, and when that’s quieted down for a few months I’ll either have a slew of smaller improvements and plugins for 1.0.0 or I’ll tag that code 1.0.0 and let it sit for bug releases or until there’s some reason to make changes again.

Leave a Reply

Your email address will not be published. Required fields are marked *