BTW, one *very* important thing to do *before* we make the steps below would be
to look very closely at the wiki and all the documentation that has been written with
1.x in mind and either update it or make sure it still applies to our new master after the
2.x merge, and 1.x maintenance branch creation.

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