This vote has passed with 3 binding +1 votes. Thanks to everyone who
contributed and tested the release candidate.
+1s:
Robert Metzger (binding)
Aljoscha Krettek (binding)
Ufuk Celebi (binding)
There are no 0s or -1s.
I'll finalize and package this release asap.
– Ufuk
On Mon, Apr 4, 2016 at
+1
- Check if checksums and GPG files match the corresponding release files
- Verify that the source archives do not contains any binaries (no
changes in commits since 1.0.0)
- Check if the source release is building properly with Maven (for
Hadoop 2.4.1 and Scala 2.10)
- Verify that the LICENSE a
+1
I ran "mvn clean verify" on the source. Dowloaded binary, ran example
programs in cluster mode.
On Mon, 4 Apr 2016 at 15:08 Maximilian Michels wrote:
> On Mon, Apr 4, 2016 at 12:16 PM, Robert Metzger
> wrote:
> > We can probably move the force shading module into a (deactivated) build
> > p
On Mon, Apr 4, 2016 at 12:16 PM, Robert Metzger wrote:
> We can probably move the force shading module into a (deactivated) build
> profile and set the dependency to 1.0.0, so that it just looks like a
> regular dependency.
That's what I suggested. It's not a blocker for the release. Just a
minor
+1 for the 1.0.1 release:
- I checked the staged files for maven. The quickstarts look good, other
modules seem to have correct scala versions
- I ran the Kafka examples (locally, against Kafka 0.8)
- Started a yarn session on a CDH 5.4.4 cluster (6 nodes) & ran a job with
rocksdb state, watermark
The scripts in master and release-1.0 had different behaviour and I
went with the behaviour in master (e.g. version X-SNAPSHOT for
force-shading, which gets updated by the change version script).
I think that we can decide this independently of this release. No one
has this as a dependency anyways
We can probably move the force shading module into a (deactivated) build
profile and set the dependency to 1.0.0, so that it just looks like a
regular dependency.
On Mon, Apr 4, 2016 at 12:12 PM, Maximilian Michels wrote:
> The version of force-shading had to be a snapshot version, otherwise
> t
The version of force-shading had to be a snapshot version, otherwise
the nightly deployment of snapshots wouldn't work. However, since we
have 1.0.0 already in place, we could revert the version to 1.0.0
again and skip the deployment from now on. I don't think it makes much
of a difference but it w
One quick question regarding the release:
Are you intentionally releasing a 1.0.1 version of the force-shading module?
Since it is really a work around, I wounder if we should not release the
force-shading anymore and always depend on force-shading:1.0.0.
On Sat, Apr 2, 2016 at 9:25 PM, Aljoscha
Yes, that seems reasonable.
On Sat, 2 Apr 2016 at 13:14 Ufuk Celebi wrote:
> Thanks for the initial tests.
>
> I would say let's continue with this RC and wait for the user to
> provide the fix, which we can then include in 1.0.2 soon.
>
> On Fri, Apr 1, 2016 at 2:59 PM, Aljoscha Krettek
> wrot
Thanks for the initial tests.
I would say let's continue with this RC and wait for the user to
provide the fix, which we can then include in 1.0.2 soon.
On Fri, Apr 1, 2016 at 2:59 PM, Aljoscha Krettek wrote:
> I ran the usual tests and the release seems fine. A user, however, found
> this bug w
I ran the usual tests and the release seems fine. A user, however, found
this bug which seems to be a blocker:
https://issues.apache.org/jira/browse/FLINK-3688?jql=project%20%3D%20FLINK
Should we maybe wait for the fix and then to another RC?
On Thu, 31 Mar 2016 at 18:10 Ufuk Celebi wrote:
> De
Dear Flink community,
Please vote on releasing the following candidate as Apache Flink version
1.0.1.
The commit to be voted on:
4afa401ab3c2b53de115d17a3157e8b80431dd10
Branch:
release-1.0.1-rc1 (see
https://git1-us-west.apache.org/repos/asf/flink/?p=flink.git;a=shortlog;h=refs/heads/release-1.
13 matches
Mail list logo
