I've just released pandoc 1.19.1 in the usual places:

Hackage (source & API docs):
https://hackage.haskell.org/package/pandoc

GitHub (binary packages & changelog):
https://github.com/jgm/pandoc/releases/tag/1.19.1

The main reason for the release (so soon after 1.19)
is to fix a serious regression in the HTML reader
affecting tables.  I recommend that anyone who is
using 1.19 upgrade to 1.19.1.

There are a few other minor improvements as well.

An update on plans for pandoc 2.0
---------------------------------

Jesse Rosenthal and I have been working on a restructuring
of the pandoc API.  This will be pandoc 2.0.

Let me explain the point of the change.  Currently pandoc
has some writers that are "pure" (they can't do IO) and
others that are not.  (In Haskell, it's built into the type
of a function whether it can do IO.)  For example, the
HTML writer is pure, while the docx writer does IO.
All of the readers are pure.

In some contexts, there are big advantages to purity.  For
example, if you're using pandoc in a web application and you
use a pure function, you can have confidence that it isn't
going to write to or read from your file system.  And pure
readers and writers are easy to parallelize and to
test deterministically.

But purity can also make things difficult.  For example,
LaTeX documents can include other files using \include
or \input or \usepackage.  Pandoc's LaTeX reader is pure,
so it can't just open these files and parse them.
Instead we have to use a hack, preprocessing the file
and doing these transclusions before passing the contents
to the LaTeX reader.

Ideally, we could choose to run each reader or writer
in "pure" or in "IO" mode, as our application requires.
Running in "pure" mode imposes certain limitations: for
example, includes can't be processed (unless we supply
a virtual directory up front).  But it also has certain
advantages, as noted above.

In pandoc 2.0 you'll be able to use each reader or writer
either as a pure function (with runPure) or in IO (with
runIO).  That's the main architectural change.

Those who use pandoc as a library will have to make some
minor changes in how they call pandoc's functions.

Those who use the command line program will see improvements
in things like include file processing and better warnings.

Anyway, that's a preview of what's to come.  I'm hoping
that maybe this will be the next release of pandoc, but if
another bad regression emerges I may need to do another
release in the 1.x series.