It's not really a release candidate in that sense, but a common test
release that everyone should work against.
This gives us a consistent view about the state at commit X, as opposed
to testing directly against the branch where it is likely everyone works
on a different version.
On 08.05.2017 09:56, Kostas Kloudas wrote:
Hi Robert,
Thanks for starting the process!
My only remark is that given that the master is unstable, does it make sense to
create an RC0?
Kostas
On May 8, 2017, at 8:52 AM, Robert Metzger <rmetz...@apache.org> wrote:
Great!
It also looks like the other big features made it also into master this
weekend.
I'll now create the feature branch and create the testing RC0.
On Sat, May 6, 2017 at 12:04 PM, Fabian Hueske <fhue...@gmail.com> wrote:
I merged the last to major features for the Table API / SQL (time
indicators and retraction support) to master.
We will need to work on some smaller issues for those features which will
take a few more days (1 week max), but the big changes are in.
Working on those final issue does not block a release candidate. The Table
API / SQL are on top of the DataStream API and runtime.
So the last fixes won't interfere with testing the lower levels of the
system.
Cheers, Fabian
2017-05-05 21:02 GMT+02:00 Stephan Ewen <se...@apache.org>:
Yes, I second Ufuk, thanks Robert and Aljoscha for the effort.
Thanks to the community for hard work on the features.
On Fri, May 5, 2017 at 4:03 PM, Ufuk Celebi <u...@apache.org> wrote:
On Fri, May 5, 2017 at 3:59 PM, Stephan Ewen <se...@apache.org> wrote:
Also, if no release candidate would be created today, it would not
make
any
difference anyways...
If no one tests a RC (if created today) over the weekend it also
wouldn't make a difference. ;-)
Thanks to all for chiming in here and Robert and Aljoscha especially
for making sure that everyone is on the same page wrt blockers etc.
