My vote would be to bring the completed issues (NH-3412 and NH-3432) into
3.4 and let the 3 other incomplete ones wait until a later release until
somebody feels it's important to dig into them for another attempt.
Regarding the question of whether those two fixes are stable enough to
include in 3.4, if they're already been triaged and are on master, we might
as well find out if they're broken sooner. Generally we find out about
problems in releases far more readily than in pre-releases, so I personally
believe that pushing out more releases with continually enhanced unit tests
(as bugs are discovered, tested, and corrected in rapid release cycles)
leads to higher quality code in the same time frame. Certainly the
reduction in time to fix (from a NuGet perspective especially) makes users
happy.
For NH-3594, it makes me think we should set up explicit 2008/2012 build
server entries... I wonder what database servers they have over there.
Based on the discussion it seems like we could make the changes only to
2012 so as to not break 2008. If it's not a regression fix seems like
you're right about it going into whichever 4.x.
We did find one regression so far in our testing of 4.0, NH-3654. I
committed a fix, keeping the code as before, but I'll need to track down my
GitHub credentials to reject that other pull request if somebody else
doesn't get to it first.
Patrick Earl
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.
