I am cool to finally get on the 2.0 kool aid and execute the plan as described by Tim
below for our next release.

+1.

Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Principal Data Scientist, Engineering Administrative Office (3010)
Manager, NSF & Open Source Projects Formulation and Development Offices (8212)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 180-503E, Mailstop: 180-503
Email: [EMAIL PROTECTED]
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 

On 8/28/17, 8:12 AM, "Konstantin Gribov" <[EMAIL PROTECTED]> wrote:

    Tim,
   
    +1 to making restructuring master to 2.x shape. If we can at least migrate
    modularization patches, dependency changes and move to java 8 it certainly
    will be a good step forward and big reduction of technical debt.
   
    On пн, 28 авг. 2017, 16:52 Bob Paulin <[EMAIL PROTECTED]> wrote:
   
    > Tim,
    >
    > +1 You've done an admirable job of dual maintenance but it sounds like
    > it became a heavy tax on development.  Releasing would allow us to get
    > back to "trunk" based development again.  Then we could focus on porting
    > any missed patches and start looking for any regressions.  I also like
    > the idea of picking up Java 8 as many other projects are starting to do
    > this.
    >
    > - Bob
    >
    >
    >
    > On 8/28/2017 8:32 AM, Allison, Timothy B. wrote:
    > > All,
    > >
    > >   We're getting some increasing deltas btwn the 2.0 and trunk branches.
    > Many of these are my fault; I gave up making updates to 2.0 around
    > April/May, I think.
    > >
    > >   What would people think of punting on some of the desired goals of 2.0
    > (e.g. chaining parsers, more structured but still simple metadata) and
    > releasing 2.0 soonish...say 2.0-BETA end of September?
    > >
    > >   We've been able to make some major improvements to Tika without
    > breaking backwards compatibility.  We _might_ be able to do that with the
    > outstanding issues for 2.0 when someone has time.
    > >
    > >   We could also do the upgrade to jdk 8 with Tika 2.0.
    > >
    > >   If this sounds reasonable, I propose creating a 1.x branch from trunk
    > for 1.x maintenance and then reworking trunk to the 2.x structure that Bob
    > Paulin so elegantly worked out.  I figure we can either copy/paste from
    > trunk to the current 2.x (and _hope_ we get all the updates) or use Bob's
    > 2.0 as a model for restructuring trunk.  At this point, I'd prefer the
    > second option.  The key here is to switch "trunk" to 2.0 so that we all
    > have the mindset that 2.0 is what we're focused on.
    > >
    > >    The main benefit of this proposal is that we'd have a more modular
    > Tika soon.
    > >
    > >    What do you think?
    > >
    > >          Best,
    > >
    > >                Tim
    > >
    >
    >
    > --
   
    Best regards,
    Konstantin Gribov
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