anchor.diff:  - convert data in database
   - restart background processes/services affected by these changes
   
  +NOTE: When you're doing `git merge` or `git cherry-pick` you usually
  +should not modify part of `migrate` files which was already included in
  +previous releases - you can make changes only after latest `VERSION` line.
  +This restriction doesn't apply to `git rebase` or in case when you're
  +fixing wrong downgrade operations for already released version.
  +
   You can run `./build` or `./build --test` at any time just to make sure
   your project builds ok and pass build-time tests.
   
  
positive.code: Generated files will be saved into `.release/` subdirectory. You can
  remove files you don't need anymore. You can re-generate files for any
  commit by running `git checkout <commit>; ./release`.
  
  === ./deploy
  
  
negative.code: executed by `./deploy` in deploy (`_live/`) directory.
  
  
  == Advanced usage
  
  === Joining multiple upgrades into one
  
  If you've released 50 versions from 1.0.0 to 1.50.0 then it may took to
  much time to deploy your project on new server because `narada-install`
  doing this step by step, version by version… plus generate 49 useless
  backups. In this case you would like to prepare alternative release for
  version 1.50.0 which you'll be able to deploy on new server in single
  step. Here is how to do this (the `<from>` is 1.0.0 and `<to>` is 1.50.0
  for this example):
  
  ----
  git checkout <to>
  git reset --soft <from>
  ----
  
  Next, modify `migrate` file by removing all `VERSION ...` lines after
  `VERSION <from>` (do not remove this one). You also may need other changes
  to make sure all migrate operations after that line will correctly migrate
  between `<from>` and `<to>`. Then:
  
  ----
  git add migrate
  git commit -m 'combined upgrade <from>-<to>'
  ./release <from>-<to>
  echo -ne 'VERSION <to>\n\n' >> .release/<from>-<to>.migrate
  ----
  
  === Merging different project versions
  
  If you've stable project branch with versions 1.x and unstable branch with
  versions 2.x, and you wanna provide upgrade path from version 1.50.0 to
  version 2.8.0, then you'll need to prepare alternative release for version
  2.8.0 (existing one will upgrade from 2.7.0). Here is how to do this (the
  `<from>` is 1.50.0 and `<to>` is 2.8.0 for this example):
  
  ----
  git checkout <from>
  git merge <to>
  ----
  
  Next, resolve conflict on `migrate` file: it must be same as it was in
  `<from>` with appended operations needed to migrate between `<from>` and
  `<to>`.
  
  Chances are this won't be ease, you may need to develop new tools for data
  migrations, and as result contents of deploy directory may not match
  original `<to>` version. In this case you'll have to release intermediate
  version first:
  
  ----
  git add .
  git commit -m 'merge upgrade <from>-<to>-pre'
  ./release <from>-<to>-pre
  ----
  
  Then act similar to "Joining multiple upgrades into one" case but keep
  current `migrate`:
  
  ----
  git checkout <to>
  git reset --soft <from>-<to>-pre
  git checkout <from>-<to>-pre migrate
  git add migrate
  git commit -m 'merge upgrade <from>-<to>'
  ./release <from>-<to>
  echo -ne 'VERSION <to>\n\n' >> .release/<from>-<to>.migrate
  ----
  
  