|
Boost : |
From: Gennaro Prota (gennaro.prota_at_[hidden])
Date: 2008-08-20 15:27:21
Beman Dawes wrote:
> Gennaro Prota wrote:
>> Daryle Walker wrote:
>>> On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
>>>
>>>> Gennaro Prota wrote:
>> [...]
>>>>> where does the release branch originate from?
>>>>
>>>> It's always from the previous release.
>>>
>>>
>>> Is this a good thing?
>>
>> Not to me. I imagine that, in a time in which I wasn't following the
>> list, there have been long discussions which led to the current state
>> of affairs. So, it may be clear to everyone except me. What I know for
>> sure is that this requires *a lot* of work every time you make a
>> modification; and either a lot of memory on your part, or a file where
>> you note the inter-release changes down, detailedly (I certainly don't
>> trust merging a whole directory (or multiple ones) blindly: I want to
>> see exactly what gets merged; and, to do this, I have to keep a list
>> of what changes I made). With such an approach, I'd expect more
>> problems due to naive merges than problems due to an unstable trunk
>> version being used as a branch point.
>
> Whoa!
Gulp! Isn't that to stop a horse? :-) (Someone warned me about having
long hair... <http://gennaro-prota.50webs.com/>).
> None of that has to be done manually. Subversion provides plenty
> of tools to manage differences between trunk and branches/release.
I'll see how it goes. Manually or not, it's a lot of bookkeeping, and
requires time. Since I'm only maintaining dynamic_bitset, I'd expect a
few number of interventions, thus I'm probably the wrong guy to
complain. But it seems to me that being a Boost developer is going to
be a full-time job, really. (With the previous repository policy, I
could make modifications to a library when I had some spare time, look
at the regression reports and forget it. Now, instead, I have also to
wait for the release branch to be open and do all the merges; which
could be e.g. two months later, in a moment I'm simply unavailable).
-- Genny
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk