>> >
>>>> >
>>>> > I almost agree with your point even if I would suggest you to use
>>>> a more
>>>> > positive tone: being sharp never encourage the community,
>>>> contribution and don't
>>>> > motivate p
end a
>>> > mail after some hard fight and disappointment so mea culpa for this
>>> one.
>>> >
>>> >
>>> >
>>> > I would add:
>>> >
>>> > - Schema or PCollection: it's already started but I th
> - Hints/Annotations on PCollection: it's something we discussed
>> during Beam
>> > Summit with Tyler and others. The idea is to mimic the Message
>> Headers in Apache
>> > Camel. It would allow us to have more dynamic IOs and transforms,
>> and give
Camel. It would allow us to have more dynamic IOs and transforms,
> and give some
> > additional statements to the runners.
> >
> >
> > +1
> >
> >
> >
> > I'm proposing to start a vote to create the 2.x branch and move
> master to Beam
&g
ection: it's something we discussed
> during Beam
> > Summit with Tyler and others. The idea is to mimic the Message
> Headers in Apache
> > Camel. It would allow us to have more dynamic IOs and transforms,
> and give some
> > additional statements t
t; additional statements to the runners.
>
>
> +1
>
>
>
> I'm proposing to start a vote to create the 2.x branch and move master to
> Beam
> 3.0.0-SNAPSHOT as join effort.
>
> Regards
> JB
>
> On 03/21/2018 08:36 AM, Romain M
SHOT as join effort.
>
> Regards
> JB
>
> On 03/21/2018 08:36 AM, Romain Manni-Bucau wrote:
> > Hi guys,
> >
> > it got mentionned but without any concrete dates: when beam 3 work will
> be started?
> >
> > I'm very interested in:
> >
> > 1. r
to Beam
3.0.0-SNAPSHOT as join effort.
Regards
JB
On 03/21/2018 08:36 AM, Romain Manni-Bucau wrote:
> Hi guys,
>
> it got mentionned but without any concrete dates: when beam 3 work will be
> started?
>
> I'm very interested in:
>
> 1. reworking the whole DAG API to ens
Hi guys,
it got mentionned but without any concrete dates: when beam 3 work will be
started?
I'm very interested in:
1. reworking the whole DAG API to ensure it is instrumentable (today the
dag uses a tons of static utilities and internals which makes it not
industrializable at all as soon
wrote:
> It is good to see so much enthusiasm about the future of Beam
> independently of the fact that we call it Beam 3 or no.
>
> I have some doubts about the idea of a release per month, Apache
> releases are designed to be slow-pace (via the 3-day voting process).
> It is just
se, if we can do both,
>> it's
>> >> perfect ;)
>> >
>> > Agree. A stable pace is the most important thing.
>>
>> +1, and I think everyone who's done a release is in favor of making it
>> easier and more frequent. Someone should put together a
t; perfect ;)
> >
> > Agree. A stable pace is the most important thing.
>
> +1, and I think everyone who's done a release is in favor of making it
> easier and more frequent. Someone should put together a proposal of
> easy things we can do to automate, etc.
>
> >>
that. Of course, if we can do both, it's
>> perfect ;)
>
> Agree. A stable pace is the most important thing.
+1, and I think everyone who's done a release is in favor of making it
easier and more frequent. Someone should put together a proposal of
easy things we can do to automate,
oth, it's
>> perfect ;)
>>
>
> Agree. A stable pace is the most important thing.
>
>
>>
>> For Beam 3.x, I wasn't talking about breaking change, but more about
>> "marketing" announcement. I think that, even if we don't break API, some
>> features are "s
it's more interesting for our community to have
> "always" a release every two months, more than a tentative of a release
> every month that end later than that. Of course, if we can do both, it's
> perfect ;)
>
Agree. A stable pace is the most important thing.
>
> For
that end later than that. Of course, if we can do both, it's perfect ;)
For Beam 3.x, I wasn't talking about breaking change, but more about
"marketing" announcement. I think that, even if we don't break API, some
features are "strong enough" to be "qualified"
do it before. I think the most important is not the period, it's more a
>> stable pace. I think it's more interesting for our community to have
>> "always" a release every two months, more than a tentative of a release
>> every month that end later than that. Of course,
; a release every two months, more than a tentative of a release
> every month that end later than that. Of course, if we can do both, it's
> perfect ;)
>
> For Beam 3.x, I wasn't talking about breaking change, but more about
> "marketing" announcement. I think that, eve
tentative of a release every month that end later than
that. Of course, if we can do both, it's perfect ;)
For Beam 3.x, I wasn't talking about breaking change, but more about "marketing"
announcement. I think that, even if we don't break API, some features are
"strong enough"
evious
> point), it would be great to have discussion about Beam 3.x. I think that
> one of interesting new feature that Beam 3.x can provide is around
> PCollection with Schemas. It's something that we started to discuss with
> Reuven and Eugene. In term of schedule,
>
I don't think
. For instance, in Apache Karaf, I have a release schedule
(http://karaf.apache.org/download.html#container-schedule). I think a release ~
every quarter would be great.
- if I see new Beam 2.x releases for sure (according to the previous point), it
would be great to have discussion about Beam 3.x. I think
21 matches
Mail list logo
