$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Request for a new submodule, tools/depinst
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-11-11 14:53:54
On 11/11/16 22:45, Rene Rivera wrote:
> On Fri, Nov 11, 2016 at 2:33 PM, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
>
>> On 11/11/16 21:26, Rene Rivera wrote:
>>
>>> On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov <lists_at_[hidden]> wrote:
>>>
>>> wgetting a random version rubs me the wrong way. Test results should be
>>>> reproducible.
>>>>
>>>
>>> Hmm.. Are you saying that getting an old version of the regression tools
>>> that "matches" a particular checkout of the libraries at some point in
>>> time
>>> should always work and be a measure of reproduction?
>>>
>>
>> I think that's correct. In my work, I have a number of scripts to build
>> various libraries, some of which are downloaded from git or other SCMs. It
>> is essential that whenever those scripts are run, they use exactly the same
>> source to build the package. This is usually achieved by checking out a
>> particular tag or revision.
>
> See my answer to this in the other response.. But essentially.. Think about
> what happens when the test infrastructure changes.
Not sure what you mean here.
> I think Boost, as a whole, should support this usage. I realize that
>> checking out a particular revision of each git submodule will always work,
>> but since we already use superproject as the synchronization means of
>> different submodules, checking out a revision of superproject should work.
>
> Haha.. That's really funny. The super project gives as much synchronization
> guarantee as a human passing around pieces of physical paper around the
> world as he makes changes to them ;-)
git checkout boost-1.62.0
git submodule update
Am I not guaranteed to have Boost 1.62 after these commands? If not,
something is terribly wrong with the release process.