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.

Reply via email to