streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suneel Marthi <smar...@apache.org>
Subject Re: Why separate Streams-Master and Streams-Project ?
Date Fri, 25 Nov 2016 20:00:44 GMT
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