Upgrade module version to v2

[pbusko]

Summary

According to https://go.dev/blog/v2-go-modules:

Starting with v2, the major version must appear at the end of the module path (declared in the module statement in the go.mod file). For example, when the authors of the module github.com/googleapis/gax-go developed v2, they used the new module path github.com/googleapis/gax-go/v2. Users who wanted to use v2 had to change their package imports and module requirements to github.com/googleapis/gax-go/v2.

Use Cases

Currently it's impossible to import the latest jam version as a dependency:

$ go mod tidy
go: errors parsing go.mod:
go.mod:10:2: require github.com/paketo-buildpacks/jam: version "v2.0.0" invalid: should be v0 or v1, not v2

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[robdimsdale]

@pbusko thanks for submitting this. Assuming we want to support jam as a library, then I agree we have to do this.

However, I didn't know folks were consuming it as a library. I didn't think that was really part of our supported surface area.

Can you help us understand how you are consuming jam as a library rather than as a CLI?

[pbusko]

Hi @robdimsdale, sorry for the delay in replying.

We have found the test matchers package for integration tests, especially useful for testing stacks.

Also, the link in the description doesn't really distinguish between CLI and non-CLI packages, it's rather an implementation detail of a module.

[ryanmoran]

Maybe we need to promote these matchers to occam?

[ForestEckhardt]

It appears that most of those matchers are being used internally for integration testing. Do we think that they should be exposed?

[robdimsdale]

Yeah, that's my thinking too. If there are matchers/test-helpers in jam that are useful beyond testing jam itself, they should be elevated to a standalone package (e.g. occam) rather than us supporting jam as a library. Especially given that the usage of jam as a library isn't actually the production code itself.

@pbusko if we ensured all the test matchers were present in occam would that be sufficient for you? Are there are other aspects of jam that you use as a library?

[pbusko]

@pbusko if we ensured all the test matchers were present in occam would that be sufficient for you? Are there are other aspects of jam that you use as a library?

No, there's nothing else we would like to consume as a library. Moving matchers to occam sounds reasonable to me.

But I'd recommend to follow the go.mod versioning scheme, since it breaks not only the library consumption, but also installtion. For example:

$ go install github.com/paketo-buildpacks/jam@v2.1.0                                                                                                                                                                                                   1
go: github.com/paketo-buildpacks/jam@v2.1.0: github.com/paketo-buildpacks/jam@v2.1.0: invalid version: module contains a go.mod file, so module path must match major version ("github.com/paketo-buildpacks/jam/v2")

[robdimsdale]

Ok, that sounds reasonable. We provide pre-built binaries for major platforms/architectures, and you can always go build the local copy of the code if you need an alternate architecture, but I think supporting go install is reasonable.

Plus, if we merge this PR and support go install, it allows you to continue importing jam as a library for the test helpers until we move them to occam.

I created paketo-buildpacks/occam#217 to capture the work to move the test helpers.

I'm inclined to merge this PR. It's more correct in that it enables standard go workflows (i.e. go install), and it pragmatically unblocks the consumers of the test helpers until we migrate those helpers to occam. @paketo-buildpacks/tooling-maintainers if you agree please free to merge.

[robdimsdale]

as far as versioning, I'm inclined to call it a patch or minor rather than a major because a major would imply bumping to v3 which obviously wouldn't work with this PR. patch makes the most sense to me - we introduced a breaking change in v2.0.0 and this patch fixes that bug.