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

Which year should the generated file's copyright year be: current or original? #823

Closed
dmitshur opened this Issue Jan 6, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@dmitshur
Member

dmitshur commented Jan 6, 2018

Currently, it's always the "current year in the local timezone". See:

Year: time.Now().Year(),

There is a CI failure after I merged PR #812 (it was created in 2017 but merged in 2018):

$ go generate -x ./... && git diff --exit-code; code=$?; git checkout -- .; (exit $code)
go run gen-accessors.go
diff --git a/github/github-accessors.go b/github/github-accessors.go
index 694d778..fe8b4b6 100644
--- a/github/github-accessors.go
+++ b/github/github-accessors.go
@@ -1,4 +1,4 @@
-// Copyright 2017 The go-github AUTHORS. All rights reserved.
+// Copyright 2018 The go-github AUTHORS. All rights reserved.
 //
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.

The command "go generate -x ./... && git diff --exit-code; code=$?; git checkout -- .; (exit $code)" exited with 1.

We need to fix the CI failure by either regenerating the file with the current year (2018), or changing the generator to use the hardcoded 2017 year.

@gmlewis Any suggestions on which direction to go?

I'm not an expert on legal stuff, but the pattern that I've seen is that the current year is used for new files, but modified files typically keep the original copyright year from when they were created. Please correct if wrong.

So, I think we should hardcode 2017 year in gen-accessors.go. Do you concur?

@gmlewis

This comment has been minimized.

Show comment
Hide comment
@gmlewis

gmlewis Jan 7, 2018

Collaborator

TL;DR: Yes, I agree with you, @shurcooL... the year 2017 should be hardcoded.

My understanding and the rule that I've been following, is when the file is created, the year is recorded in the file and the original year is retained. Some people add on additional years (e.g. 2017-2018), but just keeping the original year is sufficient and looks better, IMHO.

So I'm guessing that I'm the one that wrote time.Now().Year() which would actually be incorrect.
We should simply hard-code it to 2017 as that was when the file was originally created.

Collaborator

gmlewis commented Jan 7, 2018

TL;DR: Yes, I agree with you, @shurcooL... the year 2017 should be hardcoded.

My understanding and the rule that I've been following, is when the file is created, the year is recorded in the file and the original year is retained. Some people add on additional years (e.g. 2017-2018), but just keeping the original year is sufficient and looks better, IMHO.

So I'm guessing that I'm the one that wrote time.Now().Year() which would actually be incorrect.
We should simply hard-code it to 2017 as that was when the file was originally created.

@dmitshur dmitshur added NeedsFix and removed NeedsDecision labels Jan 9, 2018

dmitshur added a commit that referenced this issue Jan 9, 2018

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Jan 9, 2018

Member

Makes sense, thanks Glenn! I've sent PR #825 that fixes this.

Member

dmitshur commented Jan 9, 2018

Makes sense, thanks Glenn! I've sent PR #825 that fixes this.

dmitshur added a commit to anubhakushwaha/go-github that referenced this issue Jan 9, 2018

@dmitshur dmitshur closed this in #825 Jan 9, 2018

dmitshur added a commit that referenced this issue Jan 9, 2018

nbareil pushed a commit to nbareil/go-github that referenced this issue May 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment