I should have clarified.. .net framework 1.x On Thu, May 28, 2009 at 7:36 AM, Juan Pablo Araya <juanpablo.ar...@gmail.com > wrote:
> With framework 1 or iBatis 1.x? at this moment, a half of the projects > where I work user iBatis 1.6 for the datamapper, but through framework 3.5. > > > > > On Thu, May 28, 2009 at 10:20 AM, Michael McCurrey <mmccur...@gmail.com>wrote: > >> Is anybody here *actively* developing any .net 1.X software with >> iBatis.net? I would hope not. >> >> >> >> On Thu, May 28, 2009 at 7:20 AM, Michael McCurrey <mmccur...@gmail.com>wrote: >> >>> I agree with releasing 1.6.2 asap; it's stable. >>> >>> On Thu, May 28, 2009 at 7:12 AM, Yaojian <sky...@gmail.com> wrote: >>> >>>> I think the 1.6.2 beta version is quite stable, make it GA as soon as >>>> posible is a signal that indicates the project is still active. >>>> >>>> Since someone in this user group said he uses V3 release in a production >>>> enviorment and it works fine, >>>> I suggest to public the current V3 branch with some document, espically >>>> the changes from V1.x, will get more testers for V3. >>>> >>>> iBatis.NET is a great software. It's happy to see the hope of moving on >>>> again. >>>> >>>> Yaojian >>>> >>>> >>>> On Thu, May 28, 2009 at 9:03 PM, Nicholas L. Piasecki < >>>> nicho...@piasecki.name> wrote: >>>> >>>>> As a long time user of iBATIS.NET, I pretty much agree with everything >>>>> that >>>>> Rob has said here--though as a user of Castle NVelocity, I would >>>>> recommend >>>>> not touching that particular project with a 64-foot pole; I would be >>>>> concerned with iBATIS.NET acquiring that dependency if it hasn't >>>>> already. >>>>> It's a great templating language, but the implementation is not >>>>> healthy. I >>>>> also imagine that it would limit iBATIS.NET's evolution options in the >>>>> future, such as precluding the ability to pre-generate code files >>>>> instead of >>>>> inspecting an XML configuration at start up. >>>>> >>>>> As iBATIS.NET evolves, it would be nice if it continued to "grow into" >>>>> the >>>>> .NET idioms as Rob has enumerated here--things like enrolling in >>>>> System.Transaction, using the built-in <connectionStrings> in the >>>>> app.config >>>>> configuration, heck, even using the standard configuration classes at >>>>> all. >>>>> This would at least help to eliminate the necessity of >>>>> providers.config, >>>>> which has always seemed a bit odd to me. >>>>> >>>>> My only real hangup is that it'd be nice if these major feature changes >>>>> occurred in a branch that obviously contains breaking changes--e.g., >>>>> "3.0"--and not munging them together with existing maintenance 2.x >>>>> branch. >>>>> (The Castle project, MonoRail especially, has been in "Release >>>>> Candidate" >>>>> mode for seemingly its entire life, and the only way to get important >>>>> bug >>>>> fixes is to track the trunk and upgrade along with all of its new >>>>> features, >>>>> which is insane.) >>>>> >>>>> My two cents. My thanks to the community for all the hard work! >>>>> >>>>> V/R, >>>>> Nicholas Piasecki >>>>> >>>>> Software Developer >>>>> Skiviez, Inc. >>>>> n...@skiviez.com >>>>> 804-550-9406 >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Michael J. McCurrey >>> Read with me at http://www.mccurrey.com >>> >> >> >> >> -- >> Michael J. McCurrey >> Read with me at http://www.mccurrey.com >> > > -- Michael J. McCurrey Read with me at http://www.mccurrey.com
