I made a fix in sprint-2 - binary package can be built without Git now (revision will be 'n/a').
-- Val On Thu, Mar 26, 2015 at 2:42 PM, Branko Čibej <[email protected]> wrote: > 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 > >>> > >> > >
