Re: [boost] [1.37.0] branches/release open for merges

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2008-08-21 14:47:08

Robert Ramey wrote:
> Stefan Seefeld wrote:
>
>   
>>> If this shows up when a merge is made of a library into the release
>>> ready branch it should be considered a bug as it must be a break
>>> in an interface contract.
>>>       
>> I fail to understand what you are saying. As far as I know, there are
>> no 'interface contracts' on trunk. And, adding a new feature in patch
>> A, which a subsequent patch B relies on is certainly a possibility,
>> if not even likely.
>>     
>
>  It is not an attribute of the branch but of the library.
> The "interface contract" is that the library does what it's documentation
> says it does.
>   

So what ? I recently added a new feature to the boost.python library, in 
a patch I committed to trunk.
What if Joe Random tomorrow submits a separate patch, making use of this 
feature ?

What, then, if the two changesets are (separately !) considered to be 
merged into some other branch ?

>> The point I'm trying to make is that, as far as I
>> can see, there is no dependency tracking between changesets, so it
>> may be hard to tell whether a merge of any changeset from trunk to
>> the release branch will be self-contained, or rely on another merge
>> being done first.
>>     
>
> There should be no direct dependency between changesets.  If there
> is - its a bug.

Huh ?

>   Library A should depend upon, and only upon, the documented
> interface of Library B.  If merging B into the release branch breaks
> library A - then either B as changed its interface so it doesn't match
> the documentation or A wasn't incompliance with the documentation.
> Either way its a bug.
>   

First, I'm not necessarily talking about dependencies between different 
libraries, I'm talking about dependencies between patches / changesets, 
no matter what source they are applied against.

Second, the issue I'm talking about has nothing to do with whether the 
change is documented or not. The dependency between the changesets needs 
to be tracked, somehow.

Third, even if something (library or not) changes in trunk, and 
something other is added relying on this change. That doesn't yet answer 
how those two changes percolate into any release branch.

>> Anyways, my main point remains this:
>>
>> The way you treat the 'release branch' is how other projects use
>> 'trunk' for, while what you name 'trunk' is more of a 'sandbox'
>> elsewhere.
>>     
>
> Nope.  The trunk is where libraries are tested before being merged
> into the trunk.
>
> A "sandbox" would be a separate branch where experiments are
> conducted.  For this one doesn't need all the testing on various
> platforms - yet.  When the "experiment" is ready for that, then
> it gets merged into the trunk.
>   

That's your definition of a 'sandbox' and of an 'experiment'. And even 
if I buy into that: Nothing prevents me from considering the whole boost 
trunk to be such an experiment. ;-)

>> Only that boost doesn't have what other projects call release
>> branches, so you are unable to do bugfix-only releases.
>>     
>
> The release branch is almost always ready for release.  If a user
> needs a bug fix or "hot patch" - all he has to do is download it
> from there.  He can either download the whole thing or just
> the library he's interested in.
>   

That's not the only concern. As lots of people have repeatedly stated on 
this ML: the point of a bugfix-only release is to fix bugs while fully 
preserving ABI and API compatibility.

Regards
       Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...