> 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 courtesies.
>A release should be something that users can use as a dependency. . .like a >maven coordinate. 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: >> >>> Giraphers- >>> 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 >>> release >>> (http://www.mail-archive.com/general@incubator.apache.org/msg32693.html) >>> 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. >>> >>> Release notes: >>> >>> http://people.apache.org/~jghoman/giraph-0.1.0-incubating-rc0/RELEASE_NOTE >>> S.html >>> >>> Release artifacts: >>> http://people.apache.org/~jghoman/giraph-0.1.0-incubating-rc0/ >>> >>> Corresponding svn tag: >>> http://svn.apache.org/repos/asf/incubator/giraph/tags/release-0.1-rc0/ >>> >>> Our signing keys (my key doesn't seem to be being picked up by >>> http://people.apache.org/keys/group/giraph.asc): >>> http://svn.apache.org/repos/asf/incubator/giraph/KEYS >>> >>> The vote runs for 72 hours, until Friday 4pm PST. After a successful >>> vote here, Incubator will vote on the release as well. >>> >>> Thanks, >>> Jakob > >
