Re: [boost] [V1.46][Spirit] request for late minute changes to release branch

Subject: Re: [boost] [V1.46][Spirit] request for late minute changes to release branch
From: Christopher Jefferson (chris_at_[hidden])
Date: 2011-01-23 06:52:48

On 23 Jan 2011, at 10:54, Joel de Guzman wrote:

> On 1/23/2011 5:21 PM, Chris Jefferson wrote:
>> On 23 January 2011 06:28, Eric Niebler<eric_at_[hidden]>  wrote:
>>> On 1/23/2011 10:14 AM, Hartmut Kaiser wrote:
>>>> Hey release managers,
>>>> 
>>>> With the upcoming Boost release, we were planning to release a new feature
>>>> in Spirit (a dynamic data structure called utree) and everything seemed to
>>>> be fine. Unfortunately, we now discovered a flaw in the design of the new
>>>> code, which shows up under certain circumstances. The fix for that problem
>>>> changes the semantics of the utree/Spirit integration considerably.
>>>> 
>>>> Releasing utree now without being fixed means breaking its semantics with
>>>> the next release. That is something we would like to avoid.
>>>> 
>>>> We have two options:
>>>> a) fix it now, possibly delaying the release for a couple of days (until the
>>>> tests have cycled), or
>>>> b) pull utree from the release branch, which mainly means removing files and
>>>> adapting the test Jamfiles
>>>> 
>>>> Neither a) nor b) would have any consequences for other Boost code and both
>>>> are purely local to Spirit.
>>>> 
>>>> What would you suggest?
>>> 
>>> It's a new feature that nobody is using yet? How about ...
>>> 
>>> c) Leave it undocumented. Fix it in the next release.
>> 
>> I would very much prefer removing it. If I write code which uses utree
>> and send it to someone else, I wouldn't want it to compile if their
>> copy of boost has an undocumented and non-functional copy of utree in
>> it. Perhaps as least remove the "major" base headers, so it is not
>> usable.
> 
> That's a very good point, but I think Eric's intent is to be ultra
> cautious and not touch any code at all this late in the release cycle.
> I can understand that. I'm ok with b or c.

What would happen, do you suspect, if I took code which worked with the up-coming version, and tried to compile it with 1.46? Would the problems be it didn't compile (that's fine with me), or it compiled but horribly misbehaved in unpredictable ways?

Chris