streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suneel Marthi <suneel.mar...@gmail.com>
Subject Re: Why separate Streams-Master and Streams-Project ?
Date Sat, 26 Nov 2016 19:22:14 GMT
Do we wanna target this for 0.4.1 or 0.5 release ?

On Sat, Nov 26, 2016 at 10:00 AM, sblackmon <sblackmon@apache.org> wrote:

> Agreed - reopened STREAMS-255.
> On November 25, 2016 at 2:00:51 PM, Suneel Marthi (smarthi@apache.org)
> wrote:
>
> Seems like we have consensus in merging streams-master and streams-project.
> If correct, let's target this for 0.5 release.
>
> On Mon, Nov 14, 2016 at 8:21 AM, Ate Douma <ate@douma.nu> wrote:
>
> > On 2016-11-14 12:22, Suneel Marthi wrote:
> >
> >> On Mon, Nov 14, 2016 at 11:27 AM, sblackmon <sblackmon@apache.org>
> wrote:
> >>
> >>
> >>> On November 11, 2016 at 5:17:11 PM, Matt Franklin (
> >>> m.ben.franklin@gmail.com(mailto:m.ben.franklin@gmail.com)) wrote:
> >>>
> >>> On Thu, Nov 10, 2016 at 6:12 PM Suneel Marthi wrote:
> >>>>
> >>>> Why do we have 3 separate projects - Streams-master, Streams-project
> >>>>>
> >>>> and
> >>>
> >>>> streams-examples?
> >>>>>
> >>>>>
> >>>> The split between streams-master and streams-project has been there
> >>> since
> >>> the project started, I think a legacy of how Rave was organized. The
> >>> feedback related to naming (that ‘master’ is confusing given the source
> >>> code is in git) makes sense to me.
> >>>
> >>>>
> >>>>
> >>>>> While it may make sense to keep streams-examples separate from the
> >>>>>
> >>>> others,
> >>>
> >>>> what's the reasoning behind keeping separate streams-master and
> >>>>> streams-project ?
> >>>>>
> >>>>>
> >>>> Keeping the master pom separate from the rest of the project is fairly
> >>>> common within Apache. It allows things that don't change often to be
> >>>> centralized, such as developer info, etc. I am +1 for keeping it on
a
> >>>> separate release cycle and +0 for integrating it back into the main
> code
> >>>> repo.
> >>>>
> >>>> I’m -1 to separate release cycles - In reality we’re making a change
> to
> >>> the POM and/or the website, currently organized under streams-master,
> >>> every
> >>> release cycle, and it would be confusing for developers if the versions
> >>> became disconnected.
> >>>
> >>>
> >> I am -1 too for separate release cycles. I can see streams-master being
> >> modified/updated on a regular basis, given that most other dependency
> >> projects like Spark, Flink etc are on a 2 month minor release cycle and
> a
> >> 4
> >> month major release cycle (on an average).
> >>
> >
> > Maybe the real problem is that streams-master is modified/updated on a
> > regular
> > basis.
> >
> > The original idea was to (only) separate out and centralize the general
> > things
> > (like issueManagement, licensing, supported java version, developerInfo,
> > common/generic plugin configurations, etc.) which should not need to be
> > modified
> > on a regular basis. And thus also shouldn't need to be released often.
> >
> > However the master pom now indeed also defines practically all
> > dependencies,
> > which IMO should not (need to) be defined there.
> >
> > I've no real problem (+/-0) moving streams-master into streams-project,
> > however
> > that will then require streams-examples to directly depend on
> > streams-project,
> > while currently it also uses streams-master as parent.
> >
> > From a (better) separation of concern I still think using a separate
> > streams-master (which by all means can be renamed like to streams-parent)
> > would
> > be better, certainly to allow and support better modularity and
> > independent release cycles of subsets of streams in the future.
> > In the current state however there isn't much need for this, yet, and
> > separating
> > it up again when needed in the future won't be a big deal either.
> >
> > So therefore +0 if others think this is useful to do now.
> >
> > Ate
> >
> >
> >
> >> In light of the above argument, I think it makes sense to merge
> >> streams-master and streams-project.
> >>
> >>
> >>
> >>> I’m +1 to merging streams-master into streams-project - I can’t think
> of
> >>> any reasons that wouldn’t work, it would simplify build, tests, CI,
> >>> releases, and documentation. We could start by just moving the pom and
> >>> setting the parent of streams-project as a streams-parent.xml within
> the
> >>> streams-project module and putting everything except for <build> and
> >>> <plugins> in the parent.
> >>>
> >>>>
> >>>> IMO, the examples definitely deserve their own repo and release cycle.
> >>>>
> >>>> I agree.
> >>>
> >>>>
> >>>> Presently, we need to build, deploy, verify and validate 3 separate
> >>>>> projects for a release to pass, unless I am completely
> >>>>> misunderstanding/missing something here I feel streams-master and
> >>>>> streams-project can both be one project.
> >>>>>
> >>>>>
> >>>> We don't have to release master unless there is a change to dist
> >>>> management, developers, etc.
> >>>>
> >>>> In reality we’re making a change to the POM and/or the website,
> >>> currently
> >>> organized under streams-master, every release cycle, and it would be
> >>> confusing for developers if the versions became disconnected.
> >>>
> >>>>
> >>>>
> >>>>> thoughts?
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message