Skip to content
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

Merged
merged 12 commits into from
Apr 30, 2020
Merged

Flatten #692

merged 12 commits into from
Apr 30, 2020

Conversation

tfussell
Copy link
Contributor

@tfussell tfussell commented Apr 9, 2020

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

  • Update changelog in CHANGELOG.md.

@tfussell tfussell self-assigned this Apr 9, 2020
@tfussell tfussell marked this pull request as ready for review April 13, 2020 20:54
@tfussell tfussell requested a review from a team April 13, 2020 21:07
Copy link
Contributor

@stone-z stone-z left a 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

@QuentinBisson
Copy link
Contributor

Wow Thomas :)

Copy link
Contributor

@MarcelMue MarcelMue left a 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.

Copy link

@nprokopic nprokopic left a 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.

@kopiczko
Copy link
Contributor

@nprokopic no, this is only defined in go.mod file. This is already done here. So we have to import it as v6 now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants