Re: [boost] [1.36.0] Libraries with unmerged changes?

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-11 11:35:52

on Fri Jul 11 2008, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:

> "James Sharpe" <james.sharpe_at_[hidden]> wrote:
>
>
>>
>> Beman,
>>
>> I'm calling into question the decisions you've made with regards to
>> where you start a new branch for a release from in the light of the
>> fact that you are diffing against trunk. To me it seems like you are
>> making a lot of work for yourself and maintainers by requiring that
>> changes get merged from trunk to release, with release having been
>> based upon the previous release. If you're only then going to diff
>> against trunk for differences then why not just start from trunk in
>> the first place and revert commits that are destined for the next
>> release? Seems to me like you'd have a much easier job and people
>> wouldn't need to worry so much about merging before the deadline; all
>> they'd have to ensure is that there changes are in trunk before the
>> release branch creation date and then it would simply be a case of
>> reverting features that aren't destined for the release. I think this
>> would be a smaller workload for creating releases, as then the
>> remainder of the time can be spent patching the release to remove
>> regressions.
>>
>> What are people's thoughts on the matter?
>
>
> Hello,
>
> I thought this was already the case. To me this is the natural
> way. Developements that do not pretend to be included in the next
> release should be done on a separate branch or on the sandbox.

Yes, that is "standard practice."  But standard practice for projects
that care about stability is also that failures are not allowed to
persist on the trunk.  

Speaking only for myself here, it seems like we can't get people to
operate that way; a really stable trunk, and development on branches
just don't seem to be in our culture as a group.  That's why I think
we're maintaining a separate stable release branch.

So you can think of "release" as "trunk" and "trunk" as an experimental
integration branch where the latest of everything can be tested for
harmonious coexistence, I think what we're doing begins to map more
closely onto standard practice.  The only remaining strange thing is
that we never branch for release.  Instead, point releases, if they
happen, will be created on new branches spun from a previous release
tag.

> Once a release branch is created, the trunk should be free for new
> libraries, and new developements for the next release. In this way the
> delay of a release is 6 months, but a new release is delivered every
> three months. This avoid to have libraries that use something from the
> truck that will not be merged on the release branch. Of course the
> modification done on the release branch must be merged on the trunk.
>
> What is the interest to have two branches trunk and release if its
> contents must be synchronized?

I am frankly not sure why Beman is inspecting the differences; it was my
presumption that we could do development in trunk without worrying about
it, because the release branch is explicitly separated.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com