Migrations for the filesystem repository of ipfs clients
Table of Contents
When should I migrate
When you want to upgrade go-ipfs to a new version, you may need to migrate.
Here is the table showing which repo version corresponds to which go-ipfs version:
|ipfs repo version||go-ipfs versions|
1 | 0.0.0 - 0.2.3 2 | 0.3.0 - 0.3.11 3 | 0.4.0 - 0.4.2 4 | 0.4.3 - 0.4.5 5 | 0.4.6 - 0.4.10 6 | 0.4.11 - 0.4.15 7 | 0.4.16 - 0.4.23 8 | 0.5.0 - 0.6.0 9 | 0.5.0 - 0.6.0 10 | 0.6.0 - current
How to Run Migrations
Please see the migration run guide here.
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:
- SAFE. No data lost. Ever.
- Revertible. Tools must implement forward and backward migrations.
- Frozen. After the tool is written, all code must be frozen and vendored.
- To Spec. The tools must conform to the spec.
Dependencies must be vendored independently for each migration. Unfortunately, dependencies must not be vendored using go modules because we need to support multiple versions of the same dependency (for different migrations).
Feel free to join in. All welcome. Open an issue!
This repository falls under the IPFS Code of Conduct.
Want to hack on IPFS?