+1. (sorry, I am not a committer now but still like to contribute some
ideas.)
Time-based releasing schema is more from reflections on fast paced
ecosystem. More stable revisions and more features are continued to
delivered in the future release. The stability of one release is a "best
effort" in
Thanks again for all your feedback on my proposal!
The discussion was open for the last 12 days and the majority was very
positive about it.
I will keep an eye on the valid concerns Greg raised (neglected PRs,
unstable releases) and see how we can solve them.
I'll update the wiki pages and includ
Thanks a lot for your response Greg!
I'd like to hear a retrospective on the duration of the 1.2 release cycle.
164 days, or 5 months and 11 days have passed since the 1.1 release. The
other release cycles are listed here:
https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Featu
I'm +0 on switching to a pre-determined schedule. It may be that the Flink
codebase has reached a level of maturity allowing for a time-based release
schedule, and I'm hopeful that a known schedule will improve communication
about and expectations for new features.
I'd like to hear a retrospective
�&�-�ǖy�Z�_5�^��m5�2�1(���n��
Thanks a lot for the positive feedback so far.
Thank you Fabian for spotting the off by one error in my email.
"There are two hard things in computer science: cache invalidation, naming
things, and off-by-one errors." (https://twitter.com/codinghorror/status/
506010907021828096?lang=en)
I agree w
@Robert: I really like this. +1 to implement this after 1.2.0 is released.
Small note about your release dates: you started with 1.3.0 but probably meant
1.2.0 right?
On 18 January 2017 at 09:57:31, Tzu-Li (Gordon) Tai (tzuli...@apache.org) wrote:
> Hi Robert,
>
> Thanks for bringing up the di
Hi Robert,
thanks a lot for starting this discussion and for putting together the wiki
pages.
This proposal makes a lot of sense to me.
Big +1 for merging only features which are tested and *documented*.
I believe that having a clear timeline will not only make users happier but
also contributor
Hi Robert,
Thanks for bringing up the discussion. I like the proposal.
Regarding some of the downsides mentioned in the wiki:
1. Features that don’t make it in time with the feature freeze:
I think that’s ok, as long as we’re consistent with the schedules for the next
release. This way users wa
In general, I like the idea of time-based releases.
For the development process this would mean, that we would need to fork off
feature branches and work on those until the feature can be merged back
into master.
We did that already in the past when porting the Table API to Apache
Calcite and for t
Hi all!
Since the 1.2.0 release is about to come out, I would like to propose a
change in the way we do releases in the Flink community.
In my opinion, the current model leads to dissatisfaction among users and
contributors, because releases are really not predictable. A recent example
for the is
11 matches
Mail list logo
