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 >
