Thanks Max. I'm accustomed to projects advertising a release with a fixed
ref such as a sha or tag, not a branch. Much obliged.
-n
On Friday, January 15, 2016, Maximilian Michels wrote:
> Hi Nick,
>
> That was an oversight when the release was created. As Stephan
> mentioned, we have a policy t
Hi Nick,
That was an oversight when the release was created. As Stephan
mentioned, we have a policy that the corresponding final release
branch is read-only. Creating the tag is just a formality but of
course important. I've pushed a 'release-0.10.1' release tag. The
corresponding hash is 2e9b231.
All build are built equal against Hadoop, but a specific Hadoop version is
still part of the Flink lib folder when downloaded.
Cross Hadoop-version compatibility is not good, i.e., when Flink has Hadoop
2.4 in the classpath, it does not work with a 2.6 YARN installation. That
is why we pre-build m
Yes, a tag would be very good practice, IMHO. Those of us who need to run
release + patches appreciate the release hygiene :)
If all builds are created equal re: Hadoop versions, I recommend against
publishing Hadoop-specific tarballs on the downloads page; it left me quite
confused, as I'm sure i
Hi Nick!
We have not pushed a release tag, but have a frozen release-0.10.1-RC1
branch (https://github.com/apache/flink/tree/release-0.10.1-rc1)
A tag would be great, agree!
Flink does in its core not depend on Hadoop. The parts that reference
Hadoop (HDFS filesystem, YARN, MapReduce function/for
An only-slightly related question: Is Flink using Hadoop version specific
features in some way? IIRC, the basic APIs should be compatible back as far
as 2.2. I'm surprised to see builds of flink explicitly against many hadoop
versions, but 2.5.x is excluded.
-n
On Fri, Jan 8, 2016 at 9:45 AM, Nic
Hi Devs,
It seems no release tag was pushed to 0.10.1. I presume this was an
oversight. Is there some place I can look to see from which sha the 0.10.1
release was built? Are the RC vote threads the only cannon in this matter?
Thanks,
Nick