river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Release 3.0
Date Thu, 03 Sep 2015 17:53:28 GMT
Hi Greg,

Thanks for the reply, see below.

> On Sep 3, 2015, at 126PM, Greg Trasuk <trasukg@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

The questions now becomes, when to do it, and base it on what?




View raw message