I pushed a fix for NH-3638 to 3.3.x as suggested, but I really wonder what
Fabio had in mind in the first place.  I couldn't find any obvious
references on the internet and the code was there from the start. I wonder
if it was a performance hack that turned out to rely on faulty assumptions.

The branch will need to be merged into 3.4 and master, but I didn't do that
since I wondered if you wanted to add other things first.


On Wed, Aug 6, 2014 at 1:18 AM, Oskar Berggren <oskar.bergg...@gmail.com>
wrote:

> I've been looking through Jira for issues already targeting the upcoming
> releases and resolved some of them lately.
>
> This one should be easy:
> NH-3638 Was discussed in nhusers and occurs randomly in production.
> Proposed fix needs to be improved. I would like to see a fix targeting the
> 3.3.x branch and do a 3.3.3.SP2.
>
> Then there are some issues targeting 3.4.0. Mostly NH-3412 and NH-3432
> require a decision - the other seems to be of no particular importance to
> 3.4.0.
>
> https://nhibernate.jira.com/issues/?jql=project%20%3D%20NH%20AND%20fixVersion%20%3D%203.4.0.GA%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> For 4.0 there is just https://nhibernate.jira.com/browse/NH-3594 for
> which a pull request has been provided. It caused additional test failures
> however so I had to revert it. So the fix needs to be improved, but this
> could easily be a 4.0.1 item instead.
>
>
> I will do a release candidate for 4.0 this afternoon (CET), with or
> without any of the above.
>
>
> /Oskar
>
>
>
> 2014-08-06 2:05 GMT+02:00 Patrick Earl <hyn...@gmail.com>:
>
> Is there anything I can direct my energies into that could help us get the
>> release out?  I imagine you can tell I'm hoping to use it asap without
>> having to do an internal release.
>>  On Aug 1, 2014 2:43 AM, "Oskar Berggren" <oskar.bergg...@gmail.com>
>> wrote:
>>
>>> Thanks for having a look at the tests and the input on antlr! Yeah I
>>> meant just the new failing tests. I'm dealing with a failing test on
>>> Oracle, which generated some followup failures that I'm looking at now.
>>>
>>> I don't think we should do anything about relinq right now. For the
>>> future, it does open the questioin; should the nuget-build and the
>>> sourceforge-build be different? I.e. the nuget nhibernate would depend on
>>> the nuget relinq, while the sourceforge nhibernate.dll would have it
>>> embedded?
>>>
>>> /Oskar
>>>
>>>
>>>
>>> 2014-08-01 4:35 GMT+02:00 Patrick Earl <hyn...@gmail.com>:
>>>
>>>> For the unit tests, I fixed the clean builds that didn't previously
>>>> have tons of failing tests.  Were there any other specific builds you had
>>>> in mind, or just dealing with the hundreds of failing tests on all the
>>>> random dialects?
>>>>
>>>>
>>>> On Thu, Jul 31, 2014 at 12:14 AM, Patrick Earl <hyn...@gmail.com>
>>>> wrote:
>>>>
>>>>> Relating to Antlr, there's now a ReLinq release in NuGet.  What do you
>>>>> guys think about using that instead of embedding it?
>>>>>
>>>>>         Patrick Earl
>>>>>
>>>>> PS. Sorry about my extra commit on that test fix, didn't realize it
>>>>> was on both branches.
>>>>>
>>>>>
>>>>> On Wed, Jul 30, 2014 at 4:49 AM, Oskar Berggren <
>>>>> oskar.bergg...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-07-30 8:57 GMT+02:00 Patrick Earl <hyn...@gmail.com>:
>>>>>>
>>>>>> I noticed today that there hasn't yet been a release for a bug I
>>>>>>> fixed a year ago.  Another bug fix from a fellow on our team (Duncan) 
>>>>>>> was
>>>>>>> recently pulled into the 3.4 and master branches and we're anxious to 
>>>>>>> use
>>>>>>> it in production.
>>>>>>>
>>>>>>> There are more than 280 commits since the 3.3.3.SP1 release a year
>>>>>>> ago.
>>>>>>>
>>>>>>> I wanted to get some discussion going around the releases to see
>>>>>>> what we can do to improve the situation.
>>>>>>>
>>>>>>> 1. The situation is exacerbated by the version numbering that
>>>>>>> NHibernate is using for its NuGet packages.  If it numbers them 
>>>>>>> 3.3.3.4000
>>>>>>> and then 3.3.3.4001, then there's no room for somebody to inject their 
>>>>>>> own
>>>>>>> "production fix release" in between.  If the NHibernate team released 
>>>>>>> with
>>>>>>> 3.3.3.4100 for SP1, then there would plenty of space for people to put
>>>>>>> their own 3.3.3.4101 in there.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Can't see anything wrong with that change - I would happily accept
>>>>>> such a pull request. Should be a trivial change in the "build" folder
>>>>>> probably.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2. What is currently blocking 3.4 and 4.0 from being released?
>>>>>>>
>>>>>>
>>>>>> Personally I've had a lack of time during this spring. My intention
>>>>>> is to be able to devote some more time to NH again now. I've put in some
>>>>>> effort to shorten the queue of pull requests over the last couple of 
>>>>>> days,
>>>>>> since I think it would be a shame to release with so many requests open 
>>>>>> for
>>>>>> a long time.
>>>>>>
>>>>>> There were also many new failing test cases left for the various
>>>>>> builds, which I've managed to fix recently. Patches for such problems are
>>>>>> always helpful, since it does take some time to analyze problems on 
>>>>>> various
>>>>>> sql dialects.
>>>>>>
>>>>>> NH4.0 is a bit special in that it's a great opportunity to handle
>>>>>> fixes that imply larger breaking changes. I had hopes that we could do
>>>>>> something about the System.Transactions support (since I suspect it might
>>>>>> involve breaking changes), but I've given up on that for this release.
>>>>>>
>>>>>> So now there isn't very much holding up these releases actually.
>>>>>> There might be a few more pull requests that should go in, and it would 
>>>>>> be
>>>>>> cool if someone managed to finish the antlr upgrade I attempted (see
>>>>>> NH-3251).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 3. Given the modern developer's reliance on NuGet, it's
>>>>>>> significantly more difficult to just roll your own release compared to 
>>>>>>> the
>>>>>>> old days.  As such, waiting a year for bug fixes is pretty painful.  
>>>>>>> Due to
>>>>>>> this pain, I was considering moving dev to EF, but it is still lacking 
>>>>>>> in
>>>>>>> ways that are important to us. Anyways, the takeaway here is that 
>>>>>>> releasing
>>>>>>> new NuGet packages regularly is important to developers.
>>>>>>>
>>>>>>> I would go so far as to argue that it would be better to release too
>>>>>>> often and suffer the occasional bug that is rapidly fixed in the next
>>>>>>> rapidly scheduled release than to do mega releases where bugs are not
>>>>>>> addressed for another year. Release pace makes projects more attractive 
>>>>>>> not
>>>>>>> only from a user perspective, but from a contributor's. If we make 
>>>>>>> doing a
>>>>>>> release trivial (I can't say I know how much work it is now), then doing
>>>>>>> the normal continuous integration we do presently in combination with 
>>>>>>> rapid
>>>>>>> (monthy?) releases will accelerate the pace of development once again.
>>>>>>>
>>>>>>
>>>>>> The actual release process isn't too complicated (documented at
>>>>>> https://github.com/nhibernate/nhibernate-core/blob/master/ReleaseProcedure.txt).
>>>>>> It's the actual coding and patch reviewing that takes the time. So I 
>>>>>> agree
>>>>>> that more frequent minor releases would be useful.
>>>>>>
>>>>>> The decision to keep assembly version constant as long as the
>>>>>> existing API doesn't have incompatible changes was also to reduce the
>>>>>> impact of more frequent releases. But NH-3563 (NHibernate 3.3.1 API is 
>>>>>> not
>>>>>> compatible with 3.3.3) regarding the effects on GAC installation is a bit
>>>>>> disturbing. Some analysis of that would be useful.
>>>>>>
>>>>>>
>>>>>> /Oskar
>>>>>>
>>>>>>
>>>>>>  --
>>>>>>
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "nhibernate-development" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to nhibernate-development+unsubscr...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>  --
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "nhibernate-development" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to nhibernate-development+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "nhibernate-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to nhibernate-development+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nhibernate-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nhibernate-development+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nhibernate-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nhibernate-development+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nhibernate-development+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to