Commits on May 20, 2010
Commits on May 19, 2010
  1. Bumped gem deps to latest versions

    dkubb committed May 19, 2010
  2. Version bump to 1.0.0.rc2

    dkubb committed May 19, 2010
  3. Version bump to 1.0.0.rc1

    dkubb committed May 19, 2010
Commits on May 18, 2010
  1. Added guard clauses for in_memory and yaml adapters

    dkubb committed May 18, 2010
    * While yaml has some limited support for migrations, it is not complete
      and in_memory has none. Future updates may include methods for
      these adapters, but for now migrations should be considered
      unsupported for these adapters.
  2. More robust checks before checking module inclusion

    snusnu committed May 18, 2010
    Specs for in_memory and yaml still fail, but at
    least they're running now. Previously they bailed
    out immediately because of calling [] (
    on nil.
    This (like many other dm-migrations specs) looks
    kinda weird and will probably be refactored soonish
Commits on May 17, 2010
Commits on May 10, 2010
  1. Updated to the new property API

    solnic committed with dkubb May 5, 2010
  2. Stripped whitespace

    dkubb committed May 10, 2010
Commits on May 4, 2010
  1. Makes DataMapper.auto_migrate_down!/up! @api semipublic

    snusnu committed May 4, 2010
    These methods need to be overwritten in dm-constraints
    to perform down/up migration of foreign key constraints
Commits on May 3, 2010
  1. Resolved require order dependency issues

    snusnu committed May 3, 2010
    It is now possible to require 'dm-migrations'
    either before or after DataMapper.setup has been
    called, and the behavior will always be the same.
    The API for Repository and Model gets included right
    when the gem is required.
    If one or more adapters that support migrations
    are already set up, the API for these adapter(s)
    is included into all those adapters.
    In any case, a DataMapper::Adapters.const_added
    extension gets installed at the time that the gem
    gets required. This extension will make sure that
    the adapter related migrations API will get
    included into any new adapter that might get set
    up. This is guaranteed to happen if the newly set
    up adapter properly calls const_added(:AdapterName)
    after it was defined.
  2. DataMapper::Spec.setup now performs adapter setup

    snusnu committed May 3, 2010
    See for the relevant commit in
Commits on Apr 30, 2010
Commits on Apr 28, 2010
Commits on Apr 9, 2010
  1. Register the adapter extensions during DataMapper.setup

    snusnu committed Apr 9, 2010
    This means that it's not necessary anymore to require
    an explicit adapter before being able to use the
    automigration features. Previously it was necessary
    to do
      require 'dm-migrations/adapters/dm-mysql-adapter'
      DataMapper.setup(:default, 'mysql://localhost/fu')
    whereas all that's need now is
      require 'dm-migrations'
      DataMapper.setup(:default, 'mysql://localhost/fu')
    Calling DataMapper.setup will automatically require
    the dm-mysql-adapter and register the automigration
Commits on Apr 8, 2010
  1. Imported migration related code from dm-core

    snusnu committed Apr 8, 2010
    This means that the automigration features are now
    only available if dm-migrations along with at least
    one of the dm-xxx-adapter gems that support that
    feature, are required.
    Also, dm-migrations now holds the automigration
    related code for every adapter that supports the
    concept of automigration. This means that if
    adapter authors properly want to support this
    feature for their adapters, the code has to be
    put into dm-migrations.
Commits on Apr 1, 2010
  1. [dm-more] Removed unnecessary :branch => 'master' from Gemfiles

    dkubb committed Apr 1, 2010
    * The master branch is the default branch anyway, so specifying this
      explicitly was redundant.
Commits on Mar 22, 2010
Commits on Mar 20, 2010
  1. [all] Only require the gem under test in spec_helpers

    snusnu committed Mar 17, 2010
    This will make sure that all the gems require
    everything they need to be fully functional.
  2. [all] require 'dm-core' if a dm constant is used

    snusnu committed Mar 16, 2010
    1) This is a workaround for current bundler which
       doesn't yet respect the order in which the gems
       have been declared in the Gemfile, when doing a
    2) Actually I also think it's good style to require
       all the code that we need in order to perform
       a task. Even if most applications will always
       require dm-core before requiring any of its
       plugins, it still doesn't hurt to be explicit
       and to avoid possible bugs in the first place.
Commits on Jan 27, 2010
Commits on Jan 8, 2010
Commits on Dec 30, 2009
  1. [dm-more] Bumped version to 0.10.3

    dkubb committed Dec 30, 2009
Commits on Dec 12, 2009