I would also say that TIKA-930 should be resolved before a release is cut. Please see my last comment in that issue.
And it would be great if the tika-xmp module would make it in 1.2 as well :) But it does not have any impact on the ability to release like TIKA-930, of course, as it only adds a new module. Thanks Jörg -----Original Message----- From: Ray Gauss II [mailto:ray.ga...@alfresco.com] Sent: Montag, 2. Juli 2012 01:56 To: dev@tika.apache.org Subject: Re: JAX-RS overhead in tika-server Is there any consensus on TIKA-930 [1]? I don't want to wipe out properties that others feel are critical or include non-ratified standards if that's outside of policy. If there's no objection to what's outlined in that issue I can commit those changes tomorrow morning (GMT -4). Regards, Ray [1] https://issues.apache.org/jira/browse/TIKA-930 On Jul 1, 2012, at 7:22 PM, Nick Burch wrote: > On Sun, 1 Jul 2012, Mattmann, Chris A (388J) wrote: >>> It can be a big pain if an in-progress API is suddenly effectively frozen >>> by the need to be compatible into the future... >> >> Agreed -- so, what do you think? How much longer do we need to wrap up the >> API changes or whatever going on with the metadata stuff? A week? 2 weeks? > > Dunno, all my bits are in.... > > Ray? Jörg? Are there any outstanding bits left? Anything you need more > feedback/review on, before Chris does the release? > > Nick
