streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sblackmon <sblack...@apache.org>
Subject Re: Why separate Streams-Master and Streams-Project ?
Date Sat, 26 Nov 2016 15:00:04 GMT
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