I also think we shouldn't publish releases regularly, just to have a
release regularly.
Maybe we can do time-based releases more flexible: Instead of
feature-freeze after 3 months, 1 month testing. We could do it like
feature-freeze 3 months after the last release, unlimited testing. This
would limit us in not adding too many features, but enables for proper
testing for robust releases. What do you think?
Regards,
Timo
Am 23.08.17 um 10:26 schrieb Till Rohrmann:
Thanks for starting the discussion Stephan. I agree with you that the last
release was probably a bit hasty due to the constraints we put on ourselves
with the strict time based release. Therefore and because of some of the
incomplete features, I would be in favour of loosening the strict deadline
such that we have more time finishing our work and properly testing the
release. Hard to tell, however, how much more time is needed.
Cheers,
Till
On Tue, Aug 22, 2017 at 6:56 PM, Chen Qin <qinnc...@gmail.com> wrote:
I would be great to avoid immediate 1.x1 bug fixing release. It cause
confusion and raise quality concerns.
Also, is there already way to communicate with Amazon EMR for latest
release speedy available? I may try to find someone work there is needed.
Thanks
Chen
On Aug 22, 2017, at 9:32 AM, Stephan Ewen <se...@apache.org> wrote:
Hi all!
I want to bring up this discussion because we are approaching the date
when
there would be a feature freeze following the time based release
schedule.
To make it short, I would suggest to not follow the time-based schedule
for
that release. There are a bunch of reasons bringing me to that view:
- 1.3.0, which was very much pushed by the time-based schedule was not
the best release we ever made. In fact, it had quite a few open issues
that
required an immediate 1.3.1 followup and only 1.3.2 fixed some of them.
- 1.3.2, which is in some sense what 1.3.0 should have been is only 2
weeks back
- The delta since the last release is still quite small. One could argue
to make a quick release and then soon another release after that, but
releases still tie up quite a good amount of resources, so that would
introduce a delay for much of the ongoing work. I am doubtful if this is
a
good idea at this point.
- The current master has still quite a bit of "ongoing work" that is not
in perfect shape for a release, but could use some more weeks to provide
real value to users. Examples are the dependency reworking, network stack
enhancements, speedier state restore efforts, flip-6, exactly-once
sinks/side-effects, and others.
Alternatively, we could do what we did for 1.1 and 1.2, which is making
now
a list of features we want in the release, and then projecting based on
that when we fork off the 1.4 release branch.
What do you think?
Cheers,
Stephan
