fs-repo-migrations

npm-fs-repo-migrations

install fs-repo-migrations from npm

Table of Contents

• Install
• Usage
• Development
  • Publish a new version
• Contribute
• License

Install

Install the latest fs-repo-migrations binary.

npm install -g fs-repo-migrations

Installs from https://gobuilder.me/github.com/ipfs/fs-repo-migrations/cmd/ipfs.

Usage

# Install globally 
> npm install -g fs-repo-migrations
 
# Install locally 
> npm install fs-repo-migrations

See IPFS getting-started. If anything goes wrong, try using: http://ipfs.io/docs/install.

Warning: this module uses the latest version of ipfs. If there is a strong need to vendor an older version, let us know. We care about versions very much :( but for a number of reasons, this is easier for us all right now.

Development

Warning: the file bin/ipfs is a placeholder, when downloading stuff, it gets replaced. so if you run node install.js it will then be dirty in the git repo. Do not commit this file, as then you would be commiting a big binary and publishing it to npm. (TODO: add a pre-commit or pre-publish hook that warns about this)

Publish a new version

You should be able to just run ./publish.sh for example:

> ./publish.sh
usage ./publish.sh <version>
publish a version of fs-repo-migrations to npm
 
> ./publish.sh 0.3.11

This will:

• check the version is indeed a tag in https://github.com/ipfs/fs-repo-migrations
• check the size of bin/ipfs is right (must be the checked in file)
• update the version numbers in package.json and README.md
• git commit the changes
• push to https://github.com/ipfs/npm-fs-repo-migrations
• publish to fs-repo-migrations@$version to https://npmjs.com/package/fs-repo-migrations

Open an issue in the repo if you run into trouble.

Publish a new version of this module with exact same fs-repo-migrations version

If some problem happens, and you need to publish a new version of this module targetting the same fs-repo-migrations version, then please follow this convention:

1. Clean up bad stuff: unpublish all modules with this exact same <fs-repo-migrations-version>
2. Add a "hacky" version suffix: use version: <fs-repo-migrations-version>-hacky<num>
3. Publish version: publish the module. Since it's the only one with the fs-repo-migrations version, then it should be installed.

Why do this?

Well, if you previously published npm module fs-repo-migrations@0.4.0 and there was a problem, we now must publish a different version, but we want to keep the version number the same. so the strategy is to publish as fs-repo-migrations@0.4.0-hacky1, and unpublish fs-repo-migrations@0.4.0.

Why -hacky<num>?

Because it is unlikely to be a legitimate fs-repo-migrations version, and we want to support fs-repo-migrations versions like floodsub-1 etc.

Do i have to say -hacky<num> or can i just use -<num>?

-<num> won't work, as link-ipfs.js expects -hacky<num>. If you want to change the convention, go for it, and update this readme accordingly.

Contribute

Feel free to join in. All welcome. Open an issue!

This repository falls under the IPFS Code of Conduct.

License

MIT