Is there a list of api changes somewhere? I know with associations you use :model => Class vs :class_name => "Class", any other prominent gotchas?
On Jun 19, 1:36 pm, "Dan Kubb (dkubb)" <[email protected]> wrote: > I am pleased to announce the release of DataMapper 0.10.0 Release > Candidate 1. > > For the impatient, here are the command line instructions to install > it: > > Install > ------- > > 1) Add gems.datamapper.org as a gem source: > > gem sources --addhttp://gems.datamapper.org > > 2) Install the dm-core gem: > > sudo gem install dm-core > > 3) (OPTIONAL) Install whatever dm-more gems you use, eg: > > sudo gem install dm-aggregates > sudo gem install dm-constraints > sudo gem install dm-migrations > sudo gem install dm-serializer > sudo gem install dm-timestamps > sudo gem install dm-validations > sudo gem install dm-types > > 4) (OPTIONAL) Install the database driver, or adapter you plan on > using, eg: > > sudo gem install do_sqlite3 # or do_mysql/do_postgres > > NOTE: dm* and do* gems should be at version 0.10, while extlib will be > at version 0.9.13. > > NOTE: the DO gems probably need more testing with Windows, which we > are > doing right now. Ted Han will post a follow-up to this thread with > the > results of the test. > > What's New > ---------- > > The largest difference between the new 0.10 series and the new 0.9 > series > is not so much the API changes, it's the approach we've taken to > developing it. Rather than add a ton of features and bloat, we took a > step back and decided to address two of the weakest areas in DM: specs > and documentation. > > We began documenting the public and semipublic APIs for each method. > (A > public method is the part of the API that you'd be using as a > DataMapper > user, while a semipublic API is more for plugin authors). We > documented > and specced the *intended* behavior of each method, not necessarily > the actual behavior, and began working towards making those specs > pass. > > As the spec coverage grew, we began to refactor some of the DM > internals > to make things more clear, but we tried not to get carried away with > this > unless it was necessary to make things work. In some cases, like with > relationships/associations, to match the intended behavior we had to > rewrite nearly all the code. > > Even with us taking a conservative approach to rewriting internals, > there > were 2-3x more commits and changes between the 0.9 and 0.10 series > than > there were since the beginning of the DataMapper project and 0.9, so > this is a large update. > > We also rewrote the Adapter API to make things easier for adapter > authors > to make full use of the DataMapper features. In the past many > adapters > only implemented partial behavior because the backends were limited in > what they could provide in terms of matching, sorting and limiting the > results. In those cases we're now providing helper methods to fill in > any holes in the storage engine capabilities. > > What's left > ----------- > > While working on the 0.10 series we identified a number of areas of > improvement, but to avoid getting distracted we've added them to the > wiki: (Feedback welcomed) > > http://wiki.github.com/datamapper/dm-core/roadmap > > Many To Many associations are much more stable than in the 0.9 series. > One of the main reasons we decided to do this release is that we > noticed > we started spending more time telling people reporting bugs to > "try it with dm-core/next", and more often than not it did fix the > problem. Are we done with Many To Many associations? No -- there are > still a few known issues with edge cases -- but we're 95% of the way > there. > > We still need to continue documenting more of the public and > semipublic > using YARD format. Also over the next few months we're going to work > on increasing the coverage of the specs even further. > > What we need > ------------ > > We're now at the point where we need some real-world testing outside > of > a few dedicated people who have been tracking edge. If you have a > spec > suite, then please upgrade DataMapper, run your specs and report any > issues you encounter. (Fix/ignore the deprecation warnings of course) > > DataMapper is a pretty difficult project to fully spec due to it's > flexibility, and ability to use one of dozens of storage adapters. If > you do encounter a use case that we haven't covered, please submit a > ticket and we'll work on adding it to our spec suite. > > Report any issues you find in IRC, on the mailing list, or in the > tracker: > > IRC: #datamapper > Mailing List:http://groups.google.com/group/datamapper > Bug Tracker: http://datamapper.lighthouseapp.com/projects/20609-datamapper > > Please search through the existing tickets prior to submitting, but > when in doubt please create a ticket. I would rather have to sort > through dupes or tickets that turn out to be resolved/invalid than > for a valid bug to go unreported. > > Likewise if you're experiencing any problems with 0.9.x, please try > the RC1 and see if it resolves your problem. If it does, and you've > created a ticket for it, please add a comment to the ticket so we > can close the ticket. > > -- > > Dan > (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
