Go: duffle upgrade

[technosophos]

The duffle upgrade command takes a claim name and a new bundle, and it replaces the claim's old bundle with the new bundle, executing the upgrade action on the new bundle.

This one may be rather complex, so don't feel like we need to solve all of the problems.

$ duffle upgrade my_app example/my_bundle:1.2.3
# my_app is created
$ duffle upgrade my_app example/my_bundle:2.3.4

Most of the base logic can be found in duffle install in #47

[bacongobbler]

question about the syntax here... In Homebrew's model, it's a "rolling update" model in which you can only upgrade to the latest and greatest, so there's no such thing as installing a given tag. You can switch back and forth between prior versions you've installed before, but you can't "pin" to a newer version unless you've installed it before.

Given the idea that we want to reference tags, how do we want to architect the repository hosting the bundles such that we can allow users to point at a particular version of a bundle?

We could go about it a few ways:

1. Homebrew's model with a flat tree structure (this may conflict with chore: Rename manifest.json to bundle.json in ALL THE PLACES. #52 since the filename takes on the name of the bundle itself):

bundles/
    my_bundle.json
    yo_bundle.json
    your_bundle.json

2. Cargo's model with a segmented tree structure:

bundles/
    my/
        my_bundle.json
    yo/
        yo_bundle.json
        your_bundle.json

3. Store ALL THE VERSIONS in git as separate files:

bundles/
    my_bundle/
        0.1.0/
            bundle.json
            signature.prov
        0.2.0/
            bundle.json
    your_bundle/
        0.1.0/
            bundle.json

4. variant of option 3, using a slightly flatter tree structure

bundles/
    my_bundle/
        bundle-0.1.0.json
        signature-0.1.0.prov
        bundle-0.2.0.json
    your_bundle/
        bundle-0.1.0.json

5. variant of options 2 and 3, using cargo-style segmented indexing:

bundles/
    my/
        my_bundle/
            0.1.0/
                bundle.json
                signature.prov
            0.2.0/
                bundle.json
    yo/
        your_bundle/
            0.1.0/
                bundle.json

6. variant of option 1 and 2, using cargo-style segmented indexing with a rolling release:

bundles/
    my/
        my_bundle/
            bundle.json
            signature.prov
    yo/
        your_bundle/
            bundle.json

If we're allowing users to specify tags rather than a "rolling release" style of package management, I'm leaning towards option 5 as it gives us a little bit of flexibility. However, if we're leaning towards Homebrew's rolling release update model then options 1 or 6 would be the best choices.

See https://github.com/fishworks/fish-food/issues/1 for why we should consider a cargo-style model.

Scoooooooope?