On 2016-11-14 12:22, Suneel Marthi wrote:
On Mon, Nov 14, 2016 at 11:27 AM, sblackmon <sblack...@apache.org> wrote:
On November 11, 2016 at 5:17:11 PM, Matt Franklin (
m.ben.frank...@gmail.com(mailto:m.ben.frank...@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?
