Skip to content
This repository was archived by the owner on Oct 1, 2021. It is now read-only.

Commit 67449b8

Browse files
AuHaudaviddias
andauthored
Apply suggestions from code review
Co-Authored-By: David Dias <[email protected]>
1 parent 813f2aa commit 67449b8

File tree

1 file changed

+13
-10
lines changed

1 file changed

+13
-10
lines changed

README.md

Lines changed: 13 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,7 @@ This framework:
4949
* Defines migrations API
5050
* Executes and reports migrations in both directions: forward and backward
5151
* Simplifies creation of new migrations
52+
* Works on the browser too!
5253

5354
## Install
5455

@@ -93,7 +94,7 @@ To migrate your repository using the CLI, see the [how to run migrations](./run.
9394
migrations leaves the user with no way to run the migrations because there is no CLI in the browser. In such
9495
a case, you should provide a way to trigger migrations manually.**
9596

96-
### Writing migration
97+
## Creating a new migration
9798

9899
Migrations are one of those things that can be extremely painful on users. At the end of the day, we want users never to have to think about it. The process should be:
99100

@@ -106,7 +107,7 @@ If your migration has several parts, it should be fail-proof enough that if one
106107
are reverted before propagating the error. If possible then the outcome should be consistent repo so it migration could
107108
be run again.
108109

109-
#### Architecture of migrations
110+
### Architecture of a migration
110111

111112
All migrations are placed in the `/migrations` folder. Each folder there represents one migration that follows the migration
112113
API.
@@ -122,7 +123,7 @@ Each migration must follow this API. It must export an object in its `index.js`
122123
* `migrate` (function) - Function that performs the migration (see signature of this function below)
123124
* `revert` (function) - If defined then this function will revert the migration to the previous version. Otherwise it is assumed that it is not possible to revert this migration.
124125

125-
##### `migrate(repoPath, isBrowser)`
126+
#### `.migrate(repoPath, isBrowser)`
126127

127128
_Do not confuse this function with the `require('ipfs-repo-migrations').migrate()` function that drives the whole migration process!_
128129

@@ -131,7 +132,7 @@ Arguments:
131132
* `options` (object, optional) - object containing `IPFSRepo` options, that should be used to construct a datastore instance.
132133
* `isBrowser` (bool) - indicates if the migration is run in a browser environment (as opposed to NodeJS)
133134

134-
##### `revert(repoPath, isBrowser)`
135+
#### `.revert(repoPath, isBrowser)`
135136

136137
_Do not confuse this function with the `require('ipfs-repo-migrations').revert()` function that drives the whole backward migration process!_
137138

@@ -182,12 +183,12 @@ reason migrations should be well tested to ensure correct behaviour over depende
182183
An update of some dependency could introduce breaking change. In such a case the next steps should be discussed with a broader
183184
audience.
184185

185-
#### Integration with js-ipfs
186+
### Integration with js-ipfs
186187

187188
When a new migration is created, the repo version in [`js-ipfs-repo`](https://github.com/ipfs/js-ipfs-repo) should be updated with the new version,
188189
together with updated version of this package. Then the updated version should be propagated to `js-ipfs`.
189190

190-
#### Tests
191+
### Tests
191192

192193
If a migration affects any of the following functionality, it must provide tests for the following functions
193194
to work under the version of the repo that it migrates to:
@@ -199,7 +200,7 @@ If a migration affects any of the following functionality, it must provide tests
199200
Every migration must have test coverage. Tests for migrations should be placed in the `/test/migrations/` folder. Most probably
200201
you will have to plug the tests into `browser.js`/`node.js` if they require specific bootstrapping on each platform.
201202

202-
#### Empty migrations
203+
### Empty migrations
203204

204205
For interop with go-ipfs it might be necessary just to bump a version of a repo without any actual
205206
modification as there might not be any changes needed in the JS implementation. For that purpose you can create an "empty migration".
@@ -221,7 +222,7 @@ This will create an empty migration with the next version.
221222

222223
## API
223224

224-
### `migrate(path, {toVersion, ignoreLock, repoOptions, onProgress, isDryRun}) -> Promise<void>`
225+
### `.migrate(path, {toVersion, ignoreLock, repoOptions, onProgress, isDryRun}) -> Promise<void>`
225226

226227
Executes a forward migration to a specific version, or to the latest version if a specific version is not specified.
227228

@@ -244,7 +245,7 @@ Signature of the progress callback.
244245
* `counter` (int) - index of current migration.
245246
* `totalMigrations` (int) - total count of migrations that will be run.
246247

247-
### `revert(path, toVersion, {ignoreLock, options, onProgress, isDryRun}) -> Promise<void>`
248+
### `.revert(path, toVersion, {ignoreLock, options, onProgress, isDryRun}) -> Promise<void>`
248249

249250
Executes backward migration to a specific version.
250251

@@ -273,7 +274,9 @@ It has several commands:
273274

274275
For further details see the `--help` pages.
275276

276-
## Versioning
277+
## Developer
278+
279+
### Module versioning notes
277280

278281
In order to have good overview of what version of package contains what kind of migrations, this package follows this versioning schema: `0.<versionOfLastMigration>.<patches>`.
279282

0 commit comments

Comments
 (0)