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

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-16 14:49:12

Peter Dimov wrote:
> Robert Ramey:
>> Here is where we differ.  Now when someone checks in a breaking
>> change.  errors pop up all over the place in test results that the
>> author who caused the problem doesn't have any reason to check.
>> He who has had his library broken has to investigate the cause
>> of the sudden breakage and trace down to its source and then
>> complain.  This is a huge pain in the neck and costs a lot of
>> time and frustration.
>
> What's the alternative? In Boost release 1.36, libfoo 1.36 has to work
> against Boost 1.36, not Boost 1.35.

In my view it should work against both.  If not there's a bug.

> Testing it only against Boost 1.35
> allows one to be smug and claim that any failures aren't one's fault,

LOL - well there is that.  But note that I'm not suggesting that
this be the only testing done.

> but doesn't help the release process.

> Trunk does, by testing  tentative libfoo 1.36 against tentative Boost 
> 1.36.

> Sort of.

Exactly.  That's my complaint about it.

One reason my proposal isn't as clear as it should be is
that the current concempt of 1.35, 1.36 would be a little blurred.

Given a "release ready version" which is used for testing and
ready for release when the quarter comes aroud effectively
means that there is a release 1.35.1, 135.2, 135.3 .... each
time a tested library is merged in.  The only thing special
about the 1.36 release is that it would be packaged in a more
complete form , tarball, etc.

Robert Ramey