Release Plan 0.10.x, migration instructions and the future roadmap

Hey guys,

First of all, as of today I will release the first beta version of the 0.10.x version. This will follow some releases, described like in the following plan:

• beta A generally stable version, some tests are missing. documentation is lacking details.
• rc1 Providing tests to cover new programable API functionality.
• final release Polishing everything to release the final version.

As you might notice I have moved some features into later version instead and removed some release requirements. Those are not lost, but rescheduled to later releases. The next steps are to provide the missing tests and to enrich the documentation. To note all PRs that are accepted within the beta and rc state are going to be released together in the final 0.10.x version.

The master branch is now pretty ahead of the 0.9.x track, while many things have changed since then, it has kept basically completely backwards compatible. There are some things you need to know about this release, as there are some breaking changes. For example the drivers are not a part of this repository anymore. DB-Migrate now allows everyone to create their own drivers, without actually contributing directly to the project, this is actually not the only benefit of moving them out, but that by side. So now that the changes at the structure have been made I’m going to release the first beta release.

Breaking Changes

• You need to migrate old migrations under certain conditions

As of #400 we’re removing the globals async and dbm. This has the effect that your migrations are broken. We will deliver a toolset to automatically fix your existing migrations. Otherwise you could also install async and db-migrate local to your package and your old migrations start working again.

• You need to install the drivers before you can use them

Beside all that you may notice that there is actually a kind of a breaking change. Now that the drivers have moved out of db-migrate itself, you need to install them first to be able to use them.

This can be a global installation if db-migrate is installed and used globally or project wise. For example, if you have installed db-migrate globally and you want to use the mysql driver, you install the following package:

npm install -g db-migrate-mysql

• DBMigrate prefers now your local version over the global one

Another important note is that db-migrate now always prefers your local version of db-migrate. This means if you have installed db-migrate within your project and you call db-migrate within this project, it will recognize this version and execute this one instead. This makes it easier if you want to stick to a specific version on a specific project.

• Old schemas are broken under certain conditions, db-migrate now self injects into migrations

If you’re using an old schema that does a require('db-migrate') this still works, but only if you’ve have installed db-migrate locally or set the NODE_PATH environment variable to the npm global installation path, which I do not suggest to do so. If you have this old migrations you can replace the require of db-migrate. The new migration schema looks like the following, this should be easily adaptable, you basically need to insert the setup function and remove the require, but keep the definition to have the variable available in the up and down function.

'use strict';

var dbm;
var type;
var seed;

/**
  * We receive the dbmigrate dependency from dbmigrate initially.
  * This enables us to not have to rely on NODE_PATH.
  */
exports.setup = function(options, seedLink) {
  dbm = options.dbmigrate;
  type = dbm.dataType;
  seed = seedLink;
};

exports.up = function(db) {
  return null;
};

exports.down = function(db) {
  return null;
};

Future Releases

Future Releases are going to be much smaller packages, this is now much easier that the drivers are separated. The future releases have as of now the following plans:

• Make migrations and seeders zero downtime friendly
• Further working on the seeder suite and enhancing it step by step

The future releases of one drivers also already has plans, I’m going to introduce a mariadb specific driver (maybe using mariasql instead), this will include some of the new features and some of the old but not yet supported such as:

• dynamic columns
• virtual columns
• specifying the algorithm for indexes (hash, btree, rtree)
• …

<bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/27492175-release-plan-0-10-x-migration-instructions-and-the-future-roadmap?utm_campaign=plugin&utm_content=tracker%2F73887&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F73887&utm_medium=issues&utm_source=github). </bountysource-plugin>

[DjOli-zz]

Hey @wzrdtales, has there been any updates on this? Have been ignoring this problem since starting to use db-migrate late last year in the hope that some documentation or instructions would show up to aid with the “This function “insert” is deprecated and is going to be completely removed, use version controlled seeds instead.” error. I’m happy to wait for your rework as it sounds like it’s bigger than Ben Hur, just thought it was worth chasing up. Thanks 😃

[wzrdtales]

They are being removed by the way b/c db-migrate aims to be used although programatically, where global variables are a no go.