I think that we could: 1. Release 3.0 on the shortest path consistent with appropriate QA. 2a. Refactor the project structure into modules 2b. Extend the project into interesting use case areas (IoT was discussed recently).
2a and 2b could occur in parallel. A release with a project modular structure refactor would probably be another major release (4.0). It will change the way people consume the code. But it can happen as soon as the project has been modularized. (I am going through this modular project pain right now in blazegraph.) Thanks, Bryan ---- Bryan Thompson Chief Scientist & Founder SYSTAP, LLC 4501 Tower Road Greensboro, NC 27410 br...@systap.com http://blazegraph.com http://blog.bigdata.com <http://bigdata.com> http://mapgraph.io Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints APIs. Blazegraph is now available with GPU acceleration using our disruptive technology to accelerate data-parallel graph analytics and graph query. CONFIDENTIALITY NOTICE: This email and its contents and attachments are for the sole use of the intended recipient(s) and are confidential or proprietary to SYSTAP. Any unauthorized review, use, disclosure, dissemination or copying of this email or its contents or attachments is prohibited. If you have received this communication in error, please notify the sender by reply email and permanently delete all copies of the email and its contents and attachments. On Thu, Sep 3, 2015 at 1:53 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > Hi Greg, > > Thanks for the reply, see below. > > > On Sep 3, 2015, at 126PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > > >> > >> I am considering your point wrt creating a separate project, I warming > up to it, but I would really rather see River split into a multi-module > project instead of splintering off multiple repositories/projects that can > be used with the River platform. I see the Groovy configuration > implementation as part of the River platform, not an external project. > >> > > > > I think we’re in agreement. Perhaps our confusion is because I haven’t > fully explained what I mean by “separate deliverable”. I should probably > create a separate thread to talk about “projects and deliverables” and how > they relate to repositories. The gist of what I’m getting at is that a > “release” shouldn’t be a big thing. Right now, we “release” River, and it > generates 10 or so artifacts. Problem is, a good change to a single > artifact requires us to consider the impact on every other aspect of the > project. We need to reduce that coupling (given, of course, that there is > always some artifacts really do have natural coupling). > > Total agreement, see below … > > > > >> If multiple repositories/projects is the intent/direction then we can > define River core, then create stand-alone repositories/projects that > depend on River core. Move out Outrigger, Mahalo, Norm, etc … Is that what > you’d like to see? > > > >> Different projects that can be added to core River? Just curious. Would > certainly allow things to move at different velocity. > > > > Yep, that’s it in a nutshell. So if someone says “Here’s a patch that > speeds up lookups”, we can go ahead and consider it in isolation, and > release it quickly. And people could build the part they’re interested in > working on, without having to understand the existing complicated build > structure. > > This for me is really the crux of the matter. The current way of doing > things is based on one monolithic project, one big release, everything > moves at the same velocity. If we choose to make the decision that 3.0 must > be released as soon as possible, thats fine, we stick with the same > monolithic project and release lifecycle. > > I agree with what Greg is saying here, and I think we need to break the > mold, but the issue is timing. The technology we choose for project > automation does not impact the running code, but it does change how the > project does business. This allows us to change the velocity of releases, > and introduce bug fixes, enhancements and new capabilities that are more > loosely coupled. > > The questions now becomes, when to do it, and base it on what? > > Thoughts? > > Regards > > Dennis > > > > >
