Quick update:
Ufuk and me worked on fixing the last issues for 0.9.1 today, bringing the
branch up to speed for the minor release.
Ufuk de facto stepped up as release manager and will create a release
candidate later today or early tomorrow. So we can get cracking with
testing the release
I am a bit skeptical about this proposal. A bug fix release should not
change the interface and semantics of the API.
It might be possible to catch the interface changes, but it will be really
hard to ensure that the semantics are not touched.
I see that there are many important fixes in the
Aljoscha Krettek created FLINK-2577:
---
Summary: Watermarks Stall When a Source Finishes Prematurely
Key: FLINK-2577
URL: https://issues.apache.org/jira/browse/FLINK-2577
Project: Flink
I don't think we had to many API breaking changes. If everyone was careful,
maybe these are even it:
https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
I added my breaking stuff there. And of course the whole Timestamp thing is
a change, but it does not affect the normal source
Ricky Pogalz created FLINK-2576:
---
Summary: Add outer joins to API and Optimizer
Key: FLINK-2576
URL: https://issues.apache.org/jira/browse/FLINK-2576
Project: Flink
Issue Type: Sub-task
Very nice read!
On Wed, Aug 26, 2015 at 7:22 AM, Henry Saputra henry.sapu...@gmail.com wrote:
Awesome +1
- Henry
On Tue, Aug 25, 2015 at 6:39 AM, Ufuk Celebi u...@data-artisans.com wrote:
Blog post is live:
http://flink.apache.org/news/2015/08/24/introducing-flink-gelly.html
Feel free to
@Aljoscha: Correct me if I am wrong, but did the change actually break
anything user facing?
The source function and source context interface look still the same. The
underlying changes to introduce watermarks should not be visible to any
user anyways at this point (if we remove the additional
@mxm: I know the textbook theory ;-)
The whole point here is that it is not possible to do that. Fixes and major
reworks changes go together so tightly that you can get none or both.
Not having the fixes voids the purpose of the bugfix release. Having both
means it is hard to guarantee all
I'm against using the current master for 0.9.1.
It contains too many changes, posing the risk of changing APIs/semantics/...
I agree with Max that there was no consensus or discussion regarding the
scope of the 0.10 release.
How about we release a 0.9.1 version containing all fixes we can easily
The timestamp thing is one of the biggest questions.
The fixes that came as part of that pull request are crucial and hard to
pull out of the change.
On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek aljos...@apache.org
wrote:
I don't think we had to many API breaking changes. If everyone was
I went over all issues and pinged a couple of people about open issues.
Thanks for all the help! All JIRA issues tagged with fixVersion 0.9.1
should now reflect the last state of the discussion.
There is a related discussion about whether we want to release master as
0.9.1 (mod some changes).
A bugfix release should not be forked from the current master. It is
very hard to asses whether we don't break the API because there are
many small fixes going in almost daily. However, I can see applying a
subset of carefully selected commits from the master branch as an
option. Only those
I might not have made my point clear but I wrote:
However, I can see applying a subset of carefully selected commits from the
master branch as an option.
And you wrote:
We can also try and rebase a fork of the maser to the 0.9 branch, where
we select something like 70%-80% of the commits (all
+1 seems to be a viable solution
On Wed, 26 Aug 2015 at 14:51 Stephan Ewen se...@apache.org wrote:
That sounds like a very good compromise.
+1
On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske fhue...@gmail.com wrote:
I'm +1 for Robert's proposal as well.
2015-08-26 14:46 GMT+02:00 Ufuk
I'm +1 for Robert's proposal as well.
2015-08-26 14:46 GMT+02:00 Ufuk Celebi u...@apache.org:
+1
I very much like Robert's suggestion. This way we can proceed with the
0.9.1 release as planned for the remaining part and have 0.10-milestone1
with the fix.
What about the others? Please give
+1
I very much like Robert's suggestion. This way we can proceed with the
0.9.1 release as planned for the remaining part and have 0.10-milestone1
with the fix.
What about the others? Please give feedback early to allow me to proceed
with the release.
Robert's suggestion looks good. +1
Sent from my iPhone
On Aug 26, 2015, at 9:55 PM, Aljoscha Krettek aljos...@apache.org wrote:
+1 seems to be a viable solution
On Wed, 26 Aug 2015 at 14:51 Stephan Ewen se...@apache.org wrote:
That sounds like a very good compromise.
+1
On Wed,
+1 for Robert's proposal
On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske fhue...@gmail.com wrote:
I'm +1 for Robert's proposal as well.
2015-08-26 14:46 GMT+02:00 Ufuk Celebi u...@apache.org:
+1
I very much like Robert's suggestion. This way we can proceed with the
0.9.1 release as
That sounds like a very good compromise.
+1
On Wed, Aug 26, 2015 at 2:48 PM, Fabian Hueske fhue...@gmail.com wrote:
I'm +1 for Robert's proposal as well.
2015-08-26 14:46 GMT+02:00 Ufuk Celebi u...@apache.org:
+1
I very much like Robert's suggestion. This way we can proceed with the
I am +1 for this idea.
- Henry
On Wed, Aug 26, 2015 at 3:07 AM, Robert Metzger rmetz...@apache.org wrote:
I'm against using the current master for 0.9.1.
It contains too many changes, posing the risk of changing APIs/semantics/...
I agree with Max that there was no consensus or discussion
We will have a proper minor release and a preview of 0.10. After all,
a good compromise.
+1
On Wed, Aug 26, 2015 at 2:57 PM, Chiwan Park chiwanp...@icloud.com wrote:
Robert's suggestion looks good. +1
Sent from my iPhone
On Aug 26, 2015, at 9:55 PM, Aljoscha Krettek aljos...@apache.org
I think you are the best one to assess this at the moment since you are
doing the hard work of back porting the changes.
Are you suggesting this, because it is a) less error-prone/easier or b)
faster to do?
For those that haven't followed the discussion: Stephan is back porting
fixes for the
We can also try and rebase a fork of the maser to the 0.9 branch, where
we select something like 70%-80% of the commits (all fixes and reworks) and
drop the API beaking ones.
Let me try this and see how feasible it is...
On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi u...@apache.org wrote:
I
+1, good solution.
On Wed, Aug 26, 2015 at 3:11 PM, Márton Balassi balassi.mar...@gmail.com
wrote:
+1
On Wed, Aug 26, 2015 at 3:11 PM, Maximilian Michels m...@apache.org
wrote:
We will have a proper minor release and a preview of 0.10. After all,
a good compromise.
+1
On Wed,
+1
On Wed, Aug 26, 2015 at 3:11 PM, Maximilian Michels m...@apache.org wrote:
We will have a proper minor release and a preview of 0.10. After all,
a good compromise.
+1
On Wed, Aug 26, 2015 at 2:57 PM, Chiwan Park chiwanp...@icloud.com
wrote:
Robert's suggestion looks good. +1
Sent
25 matches
Mail list logo
