On 27.03.2015 00:21, Valentin Kulichenko wrote: > I made a fix in sprint-2 - binary package can be built without Git now > (revision will be 'n/a').
Nice. Have you considered scripting the process of creating the source package from Git so that you do get a valid revision and/or tag name from the build? That would certainly help in tracking down issues raised by users. -- Brane 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 >>>>> >>
