Mailing-List: contact dev-help@streams.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@streams.incubator.apache.org
MIME-Version: 1.0
References: <CAOtpBjht6rrosXHc4ye1WE7_yiXZ87ak4G+tMhcmYRt3n9YAdQ@mail.gmail.com>
 <CAENpzYUbZDf0ie=fj1aEA17A7bW8_=9znxgFKUu-HEd4wPG0Rw@mail.gmail.com>
 <etPan.582991a3.1df8139e.fbda@apache.org> <CAOtpBji8iZ-m_8eEXz-j+M9caJkuAaNUKr7aG2dvP3ut5Z_WuA@mail.gmail.com>
 <0932a7c9-c19b-ae78-5cdf-d3494b4e8aba@douma.nu> <CAOtpBjghC7sySKJ2Qf06nvyUOo8V=i5N6nN0RbnUe8hVyFBmDQ@mail.gmail.com>
 <etPan.5839a374.99b5ee5.3da@apache.org> <CAOtpBjiLi_7=3fo0AXN0gi9ENvrQOPs4O+yuTKAJohtcB=_duQ@mail.gmail.com>
 <CAJ7ACC8_nD0dLFGKczCoV8OwA5nr-w4tbouta4rZRmpuSny0ug@mail.gmail.com>
In-Reply-To: <CAJ7ACC8_nD0dLFGKczCoV8OwA5nr-w4tbouta4rZRmpuSny0ug@mail.gmail.com>
From: Matt Franklin <m.ben.franklin@gmail.com>
Date: Tue, 27 Dec 2016 22:54:02 +0000
Message-ID: <CAENpzYUJDuVo1RipRw1XFAKej9k3Z-UZjhTpVSKH5a4-AeB2jg@mail.gmail.com>
Subject: Re: Why separate Streams-Master and Streams-Project ?
To: dev@streams.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a1146e13e2a2ce80544abbb2c
archived-at: Tue, 27 Dec 2016 22:54:21 -0000

--001a1146e13e2a2ce80544abbb2c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 15, 2016 at 4:27 PM Steve Blackmon <steve@blackmon.org> wrote:

> This could be a breaking change to dependent projects.
>
> For example, if your internal streams repo's parent pom is streams-master
> and streams-master suddenly disappears in the latest release, that=E2=80=
=99s going
> to take some refactoring to fix.
>
> Additionally, there=E2=80=99s significant impact to poms, to documentatio=
n, to
> Jenkins, to the project website build and deployment process.
>
> For these reason I think it should not be rushed into a maintenance
> release.
>

I am still curious why the master file is changing so often...


>
> Steve
>
> On November 26, 2016 at 1:22:23 PM, Suneel Marthi (suneel.marthi@gmail.co=
m
> )
> wrote:
>
> 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-proje=
ct
> > >>>>>
> > >>>> and
> > >>>
> > >>>> streams-examples?
> > >>>>>
> > >>>>>
> > >>>> The split between streams-master and streams-project has been ther=
e
> > >>> since
> > >>> the project started, I think a legacy of how Rave was organized. Th=
e
> > >>> feedback related to naming (that =E2=80=98master=E2=80=99 is confus=
ing given the
> source
> > >>> code is in git) makes sense to me.
> > >>>
> > >>>>
> > >>>>
> > >>>>> While it may make sense to keep streams-examples separate from th=
e
> > >>>>>
> > >>>> 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 o=
n
> a
> > >>>> separate release cycle and +0 for integrating it back into the mai=
n
> > code
> > >>>> repo.
> > >>>>
> > >>>> I=E2=80=99m -1 to separate release cycles - In reality we=E2=80=99=
re making a change
> > to
> > >>> the POM and/or the website, currently organized under streams-maste=
r,
> > >>> 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 dependenc=
y
> > >> 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 gener=
al
> > > 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-projec=
t,
> > > 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=E2=80=99m +1 to merging streams-master into streams-project - I c=
an=E2=80=99t think
> > of
> > >>> any reasons that wouldn=E2=80=99t work, it would simplify build, te=
sts, CI,
> > >>> releases, and documentation. We could start by just moving the pom
> and
> > >>> setting the parent of streams-project as a streams-parent.xml withi=
n
> > the
> > >>> streams-project module and putting everything except for <build> an=
d
> > >>> <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 separat=
e
> > >>>>> 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=E2=80=99re making a change to the POM and/or the web=
site,
> > >>> currently
> > >>> organized under streams-master, every release cycle, and it would b=
e
> > >>> confusing for developers if the versions became disconnected.
> > >>>
> > >>>>
> > >>>>
> > >>>>> thoughts?
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> >
>

--001a1146e13e2a2ce80544abbb2c--