ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Date Fri, 27 Mar 2015 09:43:34 GMT
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').


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 <brane@apache.org> 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 <
>> dsetrakyan@gridgain.com>
>>> wrote:
>>>> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <brane@apache.org> wrote:
>>>>> On 26.03.2015 08:47, dsetrakyan@apache.org 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

View raw message