If the user cannot build a complete release from source, then the source release is not functional. It's as simple as that. The ASF releases sources, not binaries. Binaries are never official releases.
I'm really not interested in how other projects are doing it wrong; I'm interested in Ignite doing it right. If that means we need to modify the release process so that the source tarball is in a shape that allows building a binary release (as opposed to a developer build), then that's what we need to do. Two can play the second-guessing game by looking at what other projects are doing; for example, I copied the disclaimer text straight off Flex's web site. But that's unproductive: our goal should be to follow ASF release policy, which states (http://www.apache.org/dev/release.html): Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source. In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release. Note the bit about "the result of compiling that version of the source code release" and note that the 1.0.0-rc3 binary package contains libraries that are not in the source package; that's another thing that needs fixing for the next release. Also note the bit about "unapproved builds": Nobody voted on your binary package, so it's quite inappropriate to *not* warn the user about the convenience, unapproved nature of the binaries. -- Brane On 26.03.2015 18:29, Dmitriy Setrakyan wrote: > Given that we cannot do a release build of the source code without having > GIT, I think keeping the text we have on our download page is very > confusing to our users. I will go ahead and fix it for now, and I am happy > to have another discussion thread on whether to recommend binary or source > downloads. > > I also am looking at other projects, and I am seeing that they simply > provide source and binary without actually imposing any recommendation on > the user. For example, take a look at Apache Kafka download page, which is > a popular incubating project within Apache: > > http://kafka.apache.org/downloads.html > > I would prefer that we take the same approach. > > D. > > On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <[email protected]> > wrote: > >> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <[email protected]> wrote: >> >>> On 26.03.2015 08:47, [email protected] wrote: >>>> Author: dsetrakyan >>>> Date: Thu Mar 26 07:47:28 2015 >>>> New Revision: 1669287 >>>> >>>> URL: http://svn.apache.org/r1669287 >>> >>> Well, in my opinion, the source download should be first on the page, >>> not the binaries. Binaries are not official releases; the sources are. >>> We should be encouraging people to use the sources. >>> >> Brane, >> >> Our release build procedure which builds the binary, requires that you >> must be under the GIT root. The reason is that it automatically grabs the >> version from the GIT server in order to imprint it into the release. So the >> build you are suggesting does not even work. User would still be able to >> build the maven modules, but user cannot build the actual binary release, >> hence the -P-release option. >> >> I don't mind having a separate discussion about how useful it is for our >> users to build a complete binary from the source zip (and not from GIT), >> but in the mean time, I cannot call it the recommended way, because it is >> not. Do you mind if I update the text? >> >> D. >> >> >> >>> -- Brane >>> >>
