anchor.diff:  
   For the upcoming 1.7 preview releases, we're planning to focus on completing the follow-up task for the Oracle LogMiner processor and provide the support for JDBC based process too.
   We will explore incremental snapshotting support for MongoDB and do research on MariaDB support.
  +
  +== Release of 1.6.1.Final
  +
  +While the team's focus is primarily on 1.7, we've recently backported several relevant fixes to 1.6.
  +We recently released *1.6.1.Final* that fixes several bugs with multiple connectors.
  +You can check out the https://debezium.io/releases/1.6/release-notes#release-1.6.1.final[release notes] for details.
  +We recommend if you're using a release prior to 1.6, take this opportunity to upgrade and get access to the latest new features!
  
positive.code: == Incremental Snapshotting
  
  The major feature of the 1.6 release has got also new improvements.
  Oracle connector now supports incremental snapshots in the same way as the other connectors so Oracle users now can easily add new tables to the capture list and get them snapshotted on the fly.
  
  For MySQL connector, there is a new incremental snapshot mode that could be used for databases that do not allow writing to the signal table.
  https://github.com/kgalieva[Kate Galieva] invented a method based on GTID lists that could be used to provide watermarking without writing to the database. Thank you for the nice contribution!
  
  
  
negative.code: 
  == Alternative Oracle Connector LogMiner processors
  
  The Debezium connector for Oracle uses an in-memory buffer to cache in-progress transaction changes until the transaction is either committed or rolled back.
  This cache can require a significant memory footprint depending on the number of events in the transaction,
  how many concurrent transactions are in-progress,
  as well as the data itself that represents each event such as large character or binary objects.
  This can be tough to manage for some environments that continuously have ongoing long-running transactions and often required enabling transaction removal to keep the cache managed should a transaction remain in-progress for an extended period of time.
  
  This release introduces a significant refactoring to the connector processing code that allows for varied modes of processing LogMiner change events.
  Out-of-the-box the memory-based implementation remains the default,
  but we've included a new implementation based on https://infinispan.org/[Infinispan distributed data store].
  This implementation makes it possible to track any number of in-progress transactions regardless of its size or duration.
  
  This new Infinispan mode does have a few limitations:
  
  * the Infinispan configuration is not exposed outside to the user for tuning
  * there is only one cache store provided - file-based which means that the connector needs either to run on a single machine or in case of a cluster the cache store must be located on a networked filesystem
  
  This should not stop you from giving it a test drive and send as much feedback as possible to us for further improvements.
  