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.

Sign up for GitHub

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

Jump to bottom

Bump recommended Go development version in README #1340

Merged
merged 1 commit into from
Jan 19, 2022
Merged

Bump recommended Go development version in README #1340

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ For Linux and macOS binaries see the [GitHub release assets](https://github.com/

## Developer Installation

If you have Go 1.16+, you can setup a development environment:
If you have Go 1.17+, you can setup a development environment:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we bump here in the readme, we should change the go module as well

cc @mattmoor @dlorenc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not an expert on Go modules but AFAICT the Go version in go.mod has 2 effects:

  1. Restricts language features introduced after that version.
  2. Changes the behavior of the go command. In particular, for the 1.16->1.17 transition the consequential changes:
    • starts including explicit requires in go.mod for transitive dependencies
    • vendoring acts a little different (starts recording dependencies' Go versions from go.mod, omits go.mod and go.sum for vendored dependencies)

Because as of right now we still want to support 1.16, my initial thought is that (1) is a good thing for development and I'm inclined not to change it. Of course, will defer to you all :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We chatted about bumping the other one to 1.17 soon, this one seems fine as is and we can do the other one later.


$ git clone https://github.com/sigstore/cosign
$ cd cosign
Expand Down