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

From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-08-21 12:54:27

Robert Ramey wrote:

> Vladimir Prus wrote:
> 
>> On all platforms, including those that are not release platforms? Say
>> somebody commits a revision 1234567 to trunk; if there an easy way to
>> tell if it's OK to merge trunk state, as of revision 1234567 to the
>> release
>> branch? Preferrably, without manually comparing the list of release
>> compilers with the list of compilers used for trunk testing and
>> comparing revision numbers for each?
> 
> So the question is "When is it OK to merge from the trunk into release?"
> 
> I see a couple of different possible answers:
> 
> a) When the library is as good as the author can make it
> 
> b) When the library is better in at least one way than the current release
> and in no way worse.  That is when releasing the changes will
> result in an improvement for someone and cause no harm to anyone.
> 
> c) When tests pass on "release compilers"
> 
> For a new library I would prefer a).  For an improvement/bug fix to
> and existing library, I would prefer b).  Personally, I would never
> prefer c) since it opens up a whole issue of what it means to
> be "release platform" which I don't think is a very useful concept
> in this context.

Well, (a) is non-verifiable, and (b) is hard to achieve (e.g. you
cannot check "in no way worse" for toolsets that are not tested,
and "no way worse" might include non-testable things.

So, we only have test results for trunk and release branch, and
have to decide of merge from trunk and release branch is OK. All I'm
asking is whether, assuming I'm otherwise willing to do the merge,
if I can arrive at this "OK/not OK" decision without any manual investigation
and comparison of test results?

- Volodya