Re: Boost 1.36.0 release notice

Robert Ramey wrote:
> Beman Dawes wrote:
> 
>> Probably, but I don't know how to attack some of the tool problems
>> otherwise. For example, the problem of people changing the tool chain
>> without realizing it has an impact on the automated release tools, and
>> the problem of the automated release tools no longer producing some
>> component (like docs) because of a tool change, and no one noticing.
> 
> How about subjecting the tool chain the the same process as libraries are.
> That would be:
> 
> a) proposal for boost tool - e.g. docbook.
> b) enough implementation, code, and test to request formal review
> c) normal formal review process
> d) normal acceptance process.
> e) normal test procedure.
> 
> Test procedure would be similar to that of libraries.  Test files,
> expected results etc.  When all tests are passing, the release
> manager would have the option of permiting trunk version
> to be rolled into the release ready version.
> 
> This would work well with other testing and release procedures.
> That is, testing and release would use the last released tool
> version, NOT the one being refined in the trunk. This would
> be in line with what I hope will be the future of boost in that
> libraries are tested against last release and rolled into the
> release ready version as they prove that they are ready
> for prime time.

Yes, although the problems we've been having aren't so much with new 
tools as with existing tools that break unexpectedly (and/or worse yet, 
silently).

Also, the breaking change may be in a tool that Booster's don't 
maintain, such as Doxygen or xsltproc.

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost