-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flatten #692
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wild. Flatten ALL the things
Wow Thomas :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check how this impacts importing k8scc into operators. AFAIK this will cause us to lose the v6
path thingy in go modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't go modules have major version in their path? So we would have:
github.com/giantswarm/k8scloudconfig/v6
github.com/giantswarm/k8scloudconfig/v5
github.com/giantswarm/k8scloudconfig/v4
- etc.
In this golang article it says:
By definition, a new major version of a package is not backwards compatible with the previous version. This means a new major version of a module must have a different module path than the previous version. 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.
The need for major version suffixes is one of the ways Go modules differs from most other dependency management systems. Suffixes are needed to solve the diamond dependency problem.
So according to this we would continue having v6
, v5
, v4
, v3
directories, i.e. whatever is currently still being used.
@nprokopic no, this is only defined in |
Now that provider operators are all using go modules, we can get rid of old k8scc versions and only have the current version. This is a stopgap to make changes easier and faster (no more copying/wiring versions to change a single configuration line) until we get to ignition-operator.
I have tested this in
aws-operator@legacy
successfully.There could be some difficulties if we need to backport/hotfix old versions of provider operators, but we should be able to use
git checkout -b <working branch> <tag>
to create a branch module version in the future. Hopefully this won't be a common use case.Checklist