Repo migration to new org

[dan-r]

This issue outlines the impact to downstream consumers of our packages by migrating to the new org. The approach is outlined in #1737.

Golang Packages

Existing imports of Go packages pinned to a pre-migration version will continue to work. The GitHub redirect is transparent to the Go toolchain and pre-migration tags have a go.mod that still declares the old module path. This means Go's module path consistency check passes:

sequenceDiagram
    participant Go as go toolchain
    participant GH_old as github.com/hyperledger/firefly-common
    participant GH_new as github.com/hyperledger-firefly/firefly-common

    Go->>GH_old: fetch v1.5.0
    GH_old-->>Go: 301 redirect
    Go->>GH_new: fetch v1.5.0
    GH_new-->>Go: module zip + go.mod
    Note over Go: go.mod declares: github.com/hyperledger/firefly-common ✓
    Go-->>Go: build succeeds

Loading

When consumers update the version without also updating the module path in their go.mod, the go.mod in the new release declares a different path to the one required, causing an error:

sequenceDiagram
    participant Go as go toolchain
    participant GH_old as github.com/hyperledger/firefly-common
    participant GH_new as github.com/hyperledger-firefly/firefly-common

    Go->>GH_old: fetch v1.6.0
    GH_old-->>Go: 301 redirect
    Go->>GH_new: fetch v1.6.0
    GH_new-->>Go: module zip + go.mod
    Note over Go: go.mod declares: github.com/hyperledger-firefly/firefly-common ✗
    Go-->>Go: error

Loading

go: github.com/hyperledger/firefly-common@v1.6.0: parsing go.mod:
        module declares its path as: github.com/hyperledger-firefly/firefly-common
                but was required as: github.com/hyperledger/firefly-common

To update to any post-migration version, consumers must update their go.mod and all import paths across source files to the new repository.

Testing

To provide a representative test, I have created a repository through the following steps:

1. Created a repository containing a Go package at https://github.com/2ec76f8bee8a4e47c9dcd92df5eb27bc/go-package
2. Made a tag to indicate a release v0.1.0
3. Transferred this repo to https://github.com/d1070c86639b82c5758e7bf79873b21e/go-package
4. Updated go.mod to reflect the move and made a tag for a second release v0.2.0

By pulling https://github.com/d1070c86639b82c5758e7bf79873b21e/go-consumer you can recreate the testing which inform the opinions in this issue. The repo contains 3 directories for 3 scenarios:

1. 1-origin-repo-import-v1 - This represents a consumer of v0.1.0, a release made before transfer. Running go get and go run ., there are no changes compared to before migration.
2. 2-origin-repo-import-v2 - If the user from 1. attempted to update their version to v0.2.0 without changing the repo path, they see an error when running go get. From the information in this message, the user should be able to update their imports.
3. 3-dest-repo-import-v2 - Once the user adjusts their go.mod to reflect the new repo path, all works again.

Docker Images & Registry

When an repo is transferred, none of the associated images are moved so no impact to end user. After the migration, new images will be created in the new org, with past releases mirrored.

This will be the same behaviour for helm charts.

NPM

We use @hyperledger/firefly today for our Node.JS SDK. Upon migration, we mark this package as deprecated and then create packages within a new namespace/scope called @hyperledger-firefly.

Rust

Cargo handles the repository redirect without any issue.

Docs Website

We will redirect users from the new URL for all pages in the docsite. Existing URLs will continue to work.

Forks

Existing forks will be now pointing to the new repos. No impact for end consumers

[ryjones]

@dan-r if we update the 404 page, I wouldn't expect to change it. I'm sure we can do 404 routing by uri to pick the firefly stuff alone.

[dan-r]

@ryjones my intention was to add another redirect like we currently do for Caliper and Cacti pages. I'm not aware of any other ways to do this

            if (window.location.href.includes("hyperledger.github.io/caliper")) {
                const redirectLocation = window.location.href.replace(
                    "hyperledger.github.io/caliper",
                    "hyperledger-caliper.github.io/caliper"
                );
                document.getElementById("body").innerHTML = "Caliper has moved!<br/><br/>Redirecting to " + redirectLocation + " ...";
                window.location.href = redirectLocation;
            }

[ryjones]

What I meant was that I wouldn't worry about the hyperledger org changing, breaking the redirects.

[ryjones]

@dan-r may I delete the two test orgs I created?

[dan-r]

@ryjones can you leave it until the end of the week please. I'd like to do a little more testing of a few more scenarios