I'd strongly advocate for 2.  I _think_ the hard work was laying out the general structure and adding the ProxyParser workaround.  Copying and pasting/reworking into that structure will be:

A) far less dangerous than 1
And
B) we'll have a cleaner history.

On A), I know that we didn't add some major components including: configurability of parsers, completely cleaned up logging, numerous bug fixes and even entire modules (tika-dl).

On B), there were a few times where I "caught a parser up" in 2.0 not by individual commits based on the original history but based on a copy/paste from the contemporaneous master.  This obliterated the history of some commits on the 2.0 branch and would force us to look back at master.

-----Original Message-----
From: Bob Paulin [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 11, 2017 9:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Tika 2.0?

Just so it's clear are we going to:

1) Rename the 2.0 branch over to master

or

2) Re-apply the changes on master. 

I recall Chris' preference was 1 which would be quicker.  However there is very likely missed patches.  2 will be more time consuming but it would be more likely to include all the most recent code.  I'm open to either.  Not sure how far out of date 2.0 branch is so I defer to Tim on the risk of going with #1.
- Bob
On 9/11/2017 5:15 PM, Chris Mattmann wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB