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.
