I'm fine with this.
On 1/31/12 8:45 PM, Jakob Homan wrote:
I think these concerns preclude the entire idea of a release.
As mentioned above, we're releasing a tag (a specific svn revision).
That is what the release is. Both src .tar.gz and binary files are
A release should be something that users can use as a dependency. . .like a
A source release in no way prevents us from creating jars of the
release and adding them to Apache's maven repo. In fact, we can't add
a jar until we have a release.
I think you guys should wait until you have made these decisions
If you would like to assist with moving away from the munging, there
is an open JIRA to do so. Any effort would be appreciated.
To address the issues of binaries, could we release multiple binaries of Giraph
that coincide with the different versions of Hadoop?
Adding in external dependencies for a binary release (and even just
for a source release with jars that couldn't be brought in via
maven/sbt) caused significant delay recently for Kafka. I'd like to
avoid that here. Also, since we intend to release early and often,
there's no reason we can't follow up with a 0.2 in short order - there
are going to be a lot of patches in the next few weeks.
On Tue, Jan 31, 2012 at 8:17 PM, Avery Ching<ach...@apache.org> wrote:
To address the issues of binaries, could we release multiple binaries of
Giraph that coincide with the different versions of Hadoop?
On 1/31/12 7:44 PM, David Garcia wrote:
I think these concerns preclude the entire idea of a release. A release
should be something that users can use as a dependency. . .like a maven
coordinate. I think you guys should wait until you have made these
decisions. . .and then cut a binary.
On 1/31/12 5:36 PM, "Jakob Homan"<jgho...@gmail.com> wrote:
I've created a candidate for our first release. It's a source release
without a binary for two reasons: first, there's still discussion
going on about what needs to be done for the NOTICE and LICENSE files
for projects that bring in transitive dependencies to the binary
and second because we're still munging our binary against three types
of Hadoop, which would mean we'd need to release three different
binary artifacts, which seems suboptimal. Hopefully both of these
issues will be addressed by 0.2.
I've tested the release against an unsecure 20.2 cluster. It'd be
great to test it against other configurations. Note that we're voting
on the tag; the files are provided as a convenience.
Corresponding svn tag:
Our signing keys (my key doesn't seem to be being picked up by
The vote runs for 72 hours, until Friday 4pm PST. After a successful
vote here, Incubator will vote on the release as well.