2010/7/22 Emmanuel Bernard :
> Cool. Yes go ahead on 530.
done, I also included HSEARCH-565, hopefully Hudson will agree on that.
Looking forward for the release announcement :)
>
> Thanks Sanne
>
> On 22 juil. 2010, at 16:50, Sanne Grinovero wrote:
>
>> 2010/7/22 Emmanuel Bernard :
>>> Looks lik
Cool. Yes go ahead on 530.
Thanks Sanne
On 22 juil. 2010, at 16:50, Sanne Grinovero wrote:
> 2010/7/22 Emmanuel Bernard :
>> Looks like a good candidate for back port indeed.
>> Add the 3.2.1 version to the existing bug, that's the easiest solution.
>
> Hi, I merged HSEARCH-534 in the the 3.2 b
2010/7/22 Emmanuel Bernard :
> Looks like a good candidate for back port indeed.
> Add the 3.2.1 version to the existing bug, that's the easiest solution.
Hi, I merged HSEARCH-534 in the the 3.2 branch.
If you agree with it I could spend some minutes to merge HSEARCH-530
too, I don't see more inte
Looks like a good candidate for back port indeed.
Add the 3.2.1 version to the existing bug, that's the easiest solution.
On 22 juil. 2010, at 00:47, Sanne Grinovero wrote:
> Hello,
> maybe HSEARCH-534 could be considered: non-intrusive change, nasty bug too.
> What's the procedure? I suppose
Hello,
maybe HSEARCH-534 could be considered: non-intrusive change, nasty bug too.
What's the procedure? I suppose 1) edit "fix versions" to add the
3.2.1 2) merge the changeset in the branch
or should we also open a new issue, or reopen the same one?
2010/7/19 Emmanuel Bernard :
> Since 3.3 is no
Since 3.3 is not out yet (likely an end of summer target), I'm thinking on
releasing a maintenance version of the 3.2 series.
HSEARCH-540 is a pretty nasty bug (due to lack of Synchronization execution
ordering - see Re: [hibernate-dev] Exceptions thrown in a tx synchronization
are eaten by Stev
