Nightly release fail after 2.0

[squakez]

go: errors parsing go.mod:
/home/runner/work/camel-k/camel-k/go.mod:7:2: require github.com/apache/camel-k/pkg/apis/camel: version "v2.0.0-nightly" invalid: should be v0 or v1, not v2
/home/runner/work/camel-k/camel-k/go.mod:8:2: require github.com/apache/camel-k/pkg/client/camel: version "v2.0.0-nightly" invalid: should be v0 or v1, not v2
/home/runner/work/camel-k/camel-k/go.mod:9:2: require github.com/apache/camel-k/pkg/kamelet/repository: version "v2.0.0-nightly" invalid: should be v0 or v1, not v2
make: *** [Makefile:345: build-resources] Error 1

there must be some check limiting the major release.

[squakez]

TestKameletClasspathLoading fails in v1.12 branch

[squakez]

This one seems to be not straightforward as moving to v2 in Go is quite complicated. We have several modules and we may take the opportunity to move to Go workpsaces.

[squakez]

• main branch broken because issues with moving to v2
• release 1.12 branch broken because TestKameletClasspathLoading check error fix(test): code refactoring #4104
• release 1.10 branch broken because Health and Jolokia trait errors

[squakez]

@claudio4j I think you are familiar with the 1.10 issue that may be related to some missing backport after Jolokia switch, do you mind having a look?

[claudio4j]

@squakez how the code is changed to reproduce the problem ? Do you have a branch ?

[squakez]

@claudio4j nightly releases smoke tests are failing in release-1.10.x: https://github.com/apache/camel-k/actions/runs/4338772318/jobs/7575742188 I think it would be enough to run the common test to reproduce.

[claudio4j]

The 1.10.x e2e jolokia test is failing because the jolokia trait change is present in 1.10.x branch, and the accompanying change in camel-k-runtime must be released as 1.15.3, which I already requested in camel dev mailing list.
Note that camel-k 1.10.4 users are not affected, since the camel-k change was commited after 1.10.4 release.

[claudio4j]

This one seems to be not straightforward as moving to v2 in Go is quite complicated. We have several modules and we may take the opportunity to move to Go workpsaces.

It's my understanding go workspaces may help with the replaces directive in go.mod, but the major pain is to actually accomodate the /v2 to upgrade the version, that's a pity.
As an example, there is github.com/google/go-github/v32 which is a lot. I suppose they must have some script to update the version, but that seems not good to force the client users to constantly update the versions in the import section.