Hey Wade,

For code to be part of a release version, you also have to merge your
changes to the relevant release branch. So seeing as you commited the
changes in r14006, your next action should have been to merge the
changes made in r14006 to the release-1.7 branch. I'll merge the
changes later this day.

Best regards,
Tobias

2009/2/12 Wade Arnold <[email protected]>:
> I am not sure what I did wrong here. I checked in the code to trunk. It
> seems like I set it to 1.7.4 rather than next mini version. Please let me
> know what I can do in order to get this into the next mini release.
>
> Thanks!
> Wade
>
>
>
> On 2/12/09 4:27 AM, "Tobias Gies" <[email protected]> wrote:
>
>> The "fix for" attribute of this issue is indeed misleading. AFAIK,
>> these get set automatically on release, but alas, they are not always
>> true.
>>
>> Wade, please decide what to do by 7PM UTC. If I hear nothing from you,
>> I'll merge the patch to the release branch.
>>
>> Best regards,
>> Tobias
>>
>> 2009/2/12 Dirk Thomas / 4wd media <[email protected]>:
>>> Hi Tobias,
>>>
>>>> Sorry, I really forgot about the issue.
>>>
>>> no problem - you don't have to apologize.
>>>
>>>> If it's already in trunk, Wade
>>>>
>>>> will have to decide if it should be merged to the release branch.
>>>
>>> The point is that the issue is is targeted for 1.7.4 in the tracker.
>>>
>>> How do you keep track which things to merge?
>>> In our company the issue is not closed until it has been fixed AND merged
>>> (to any branches required to).
>>>
>>> If i would know how this is handled for Zend Framework i would may be just
>>> keep quiet when i know that the issue is still remembered for merging...
>>>
>>> Thank you,
>>> Dirk
>>>
>
>

Reply via email to