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
