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" <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> 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 < >>> [email protected]> wrote: >>> >>>> >>>> >>>> >>>> 2014-07-30 8:57 GMT+02:00 Patrick Earl <[email protected]>: >>>> >>>> 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 [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
