Consider deprecating old migrations

[hsanjuan]

• No one should be having to upgrade from really old versions
• Users can always download an old version of fs-repo-migrations (workarounds exist)
• Reduce maintenance burdens, code-size, binary size, number of tests
• Cannot realistically spend time helping users on go-ipfs versions from 2 years ago
• 5-to-6 migration is from 2017
• 6-to-7 is from June 2018
• Suggest to keep anything from 7 upwards.

[hsanjuan]

Unfortunately, anything that directly or indirectly depends on badger will break with:

panic: /debug/requests is already registered. You may have two independent copies of golang.org/x/net/trace in your binary, trying to maintain separate state. This may involve a vendored copy of golang.org/x/net/trace.

This happens because old migrations have old gxed versions of things.

[Stebalien]

Hm. Annoying. We could change how we vendor the trace library...

We really can't deprecate old migrations. Users may have old archived repos sitting around and we want to support reading from these repos.

[hsanjuan]

We could change how we vendor the trace library...

I hacked it so things work for now. It will probably be a pain to align all migration submodules to use the same net/trace in the future, but for now things are ok.

[gammazero]

@hsanjuan

I hacked it so things work for now. It will probably be a pain to align all migration submodules to use the same net/trace in the future, but for now things are ok.

This is now fixed permanently. Each migration is a separate binary, and all dependencies are vendored into each migration. There are no shared dependencies, and fs-repo-migrations downloads all necessary migration binaries and executes them in order.

[gammazero]

No longer necessary as noted in the previous comment. Closing.

[hsanjuan]

Thank you @gammazero , you resolved a big mess.