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 <[email protected]>wrote: > I agree with releasing 1.6.2 asap; it's stable. > > On Thu, May 28, 2009 at 7:12 AM, Yaojian <[email protected]> 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 < >> [email protected]> 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. >>> [email protected] >>> 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
