ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: [VOTE] Apache Ignite 1.0.0 release
Date Tue, 31 Mar 2015 00:33:31 GMT
On 31.03.2015 02:08, Dmitriy Setrakyan wrote:
> Thanks Brane! I will be submitting this release to IPMC for the final vote
> today. Also some comments are below.
>
> On Mon, Mar 30, 2015 at 4:54 PM, Branko ─îibej <brane@apache.org> wrote:
>
>> On 31.03.2015 00:54, Konstantin Boudnik wrote:
>>> On Mon, Mar 30, 2015 at 03:39PM, Dmitriy Setrakyan wrote:
>>>> On Mon, Mar 30, 2015 at 2:17 PM, Konstantin Boudnik <cos@apache.org>
>> wrote:
>>>>> On Mon, Mar 30, 2015 at 12:54PM, Dmitriy Setrakyan wrote:
>>>>>> Cos,
>>>>>>
>>>>>> Thanks for the vote! I think the whole PPMC voted as well.
>>>>> I think 3 ppl from PPMC have voted, which is not "the whole PPMC" but
>>>>> enough
>>>>> to start the vote on general@incubator.a.o
>>>>>
>>>> I counted Yakov, Valentin, Semyon, Serj, and Vladimir have voted, so
>> seems
>>>> like 5 PPMC votes and 1 from IPMC (Cos).
>>> Sorry, I missed two as a part of this thread  has been already moved to a
>>> different folder. You're right of course.
>> Even so, there are 17 PPMC members, 14 of these are not mentors,
>> according to
>>
>>     http://incubator.apache.org/projects/ignite.html
>>
>> and I think 14 > 5 so it's indeed not "the whole PPMC". :)
>>
>>
>> +1 for release but the following problems should be fixed for the next
>> release:
>>
>>
>> 1. After building with ... and running bin/ignite.sh I get the following
>> message:
>>
>> Ignite ver. 1.0.0#19700101-sha1:n/a
>>
>> There are two problems here:
>>
>>   * The date is wrong
>>   * There's not commit ID and/or tag name
>>
>> IMO, the source package should be generated by a script that:
>>
>>   * creates a tag in the repository;
>>   * exports the contents of the tagged tree
>>   * updates the exported tree:
>>       o sets the current date (and time?) for version display
>>       o sets the tag name for same
>>
>> The point is that the user should be able to take the source package and
>> produce release-grade binaries with all the version references (dates,
>> commit IDs, etc); and the convenience binaries should be built from the
>> source package, not from a Git checkout.
>>
> Agree on fixing the date, but not sure about the commit tag. The user may
> theoretically change half of the code before rebuilding, so adding the
> commit tag really carries little value in my view and actually can end up
> misleading everyone that the release is based on our GIT tree.


The user can fork the Git repo and change half of the code and generate
a release from there ... and the resulting version would be just as
misleading. The user can tweak just the version number and date in the
source to make the resulting binaries look like they were generated from
out Git tree.

Anyone who significantly changes the code and redistributes the result
should change the package name, too. If the changes are minimal, I'd
expect an annotation in the version number.


This is why we do not release official binaries, only official sources,
and the fact that the released official sources are indeed based on our
Git tree is easily verifiable because we have package signatures and hashes.

-- Brane

Mime
View raw message