You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 1, 2021. It is now read-only.
Copy file name to clipboardExpand all lines: README.md
+13-10Lines changed: 13 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -49,6 +49,7 @@ This framework:
49
49
* Defines migrations API
50
50
* Executes and reports migrations in both directions: forward and backward
51
51
* Simplifies creation of new migrations
52
+
* Works on the browser too!
52
53
53
54
## Install
54
55
@@ -93,7 +94,7 @@ To migrate your repository using the CLI, see the [how to run migrations](./run.
93
94
migrations leaves the user with no way to run the migrations because there is no CLI in the browser. In such
94
95
a case, you should provide a way to trigger migrations manually.**
95
96
96
-
### Writing migration
97
+
##Creating a new migration
97
98
98
99
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:
99
100
@@ -106,7 +107,7 @@ If your migration has several parts, it should be fail-proof enough that if one
106
107
are reverted before propagating the error. If possible then the outcome should be consistent repo so it migration could
107
108
be run again.
108
109
109
-
####Architecture of migrations
110
+
### Architecture of a migration
110
111
111
112
All migrations are placed in the `/migrations` folder. Each folder there represents one migration that follows the migration
112
113
API.
@@ -122,7 +123,7 @@ Each migration must follow this API. It must export an object in its `index.js`
122
123
*`migrate` (function) - Function that performs the migration (see signature of this function below)
123
124
*`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.
124
125
125
-
##### `migrate(repoPath, isBrowser)`
126
+
####`.migrate(repoPath, isBrowser)`
126
127
127
128
_Do not confuse this function with the `require('ipfs-repo-migrations').migrate()` function that drives the whole migration process!_
128
129
@@ -131,7 +132,7 @@ Arguments:
131
132
*`options` (object, optional) - object containing `IPFSRepo` options, that should be used to construct a datastore instance.
132
133
*`isBrowser` (bool) - indicates if the migration is run in a browser environment (as opposed to NodeJS)
133
134
134
-
##### `revert(repoPath, isBrowser)`
135
+
####`.revert(repoPath, isBrowser)`
135
136
136
137
_Do not confuse this function with the `require('ipfs-repo-migrations').revert()` function that drives the whole backward migration process!_
137
138
@@ -182,12 +183,12 @@ reason migrations should be well tested to ensure correct behaviour over depende
182
183
An update of some dependency could introduce breaking change. In such a case the next steps should be discussed with a broader
183
184
audience.
184
185
185
-
####Integration with js-ipfs
186
+
### Integration with js-ipfs
186
187
187
188
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,
188
189
together with updated version of this package. Then the updated version should be propagated to `js-ipfs`.
189
190
190
-
####Tests
191
+
### Tests
191
192
192
193
If a migration affects any of the following functionality, it must provide tests for the following functions
193
194
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
199
200
Every migration must have test coverage. Tests for migrations should be placed in the `/test/migrations/` folder. Most probably
200
201
you will have to plug the tests into `browser.js`/`node.js` if they require specific bootstrapping on each platform.
201
202
202
-
####Empty migrations
203
+
### Empty migrations
203
204
204
205
For interop with go-ipfs it might be necessary just to bump a version of a repo without any actual
205
206
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.
Executes backward migration to a specific version.
250
251
@@ -273,7 +274,9 @@ It has several commands:
273
274
274
275
For further details see the `--help` pages.
275
276
276
-
## Versioning
277
+
## Developer
278
+
279
+
### Module versioning notes
277
280
278
281
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>`.
0 commit comments