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 <a...@douma.nu> wrote: > 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? >>>>> >>>>> >>> >>> >> > >
