Keep copyright year up-to-date

[ameyms]

Get ready for 2014 (and every year after that) ! 🎉
Auto update copyright year directly through the Grunt script. 📆

[mgol]

That's cool! We have other places where we use 2013 explicitely so it'd be good if we could fix the rest at the same time.

[ameyms]

Thanks.
There are 2 other places https://github.com/jquery/jquery/search?q=2013&source=c

Should I add it to this PR?

[scottgonzalez]

There are other locations that can't be dynamic. So I'm not sure how much this helps.

[ameyms]

We could use something like https://npmjs.org/package/grunt-text-replace to replace those other two as well.

[scottgonzalez]

That actually seems like a really bad idea, unless the changes are going to be committed back to the source files.

[ameyms]

Yes ofcourse.
We need to find the copyright year in the files, and replace text in files if copyright year is not equal to grunt.template.today('yyyy')

It can very well be a build step.

[mgol]

@ameyms Could you also update the build task in a similar way we replace @DATE now? (see https://github.com/jquery/jquery/blob/master/build/tasks/build.js#L223)

@scottgonzalez Why can't it be automatic here? Are there any law-related concerns? intro.js is the only other place that contains the year.

[ameyms]

@mzgol I guess even the LICENSE file contains the copyright year.

I make the changes i other places that you have mentioned.

[mgol]

Right, forgot about the LICENSE file. In that one we can't use the @YEAR text, it has to be a proper year so we'd need a little different code, changing Copyright ANY_FOUR_DIGITS to Copyright CURRENT_YEAR.

@scottgonzalez Is this an OK thing to do? Changes would be commited to the repository, of course.

[scottgonzalez]

No matter what we do, the changes need to be committed to the repo prior to tagging. If this were implemented today and we released v2.3.4, then a year from today if someone rebuilds v2.3.4 from the tag, using whatever build process we have in place (today that's Grunt), then the copyright on the generated build should be 2013, not 2014.

As for Copyright \d{4} replacements, that could potentially work, but this whole process needs to happen on its own, as one of the first things that happens during the year. This is a much bigger problem than just keeping this specific repo updated every year.

[ghost]

. Ez egy sokkal nagyobb probléma, mint tartani a konkrét repo frissítik
minden : v2.3.4 a tag, segítségével bármilyen épít folyamat van a helyén (a
mai ez Grunt)(#1384) (Tartsa copyright év up-to-date (# 1384))
@ Scottgonzalez https://github.com/scottgonzalez -@
Mzgolhttps://github.com/mzgol Azt
hiszem,-@ Scottgonzalez https://github.com/scottgonzalez Ez egy OK--Copyright
ANY_FOUR_DIGITS a Copyright CURRENT_YEAR .

2013/11/11 Scott González notifications@github.com

No matter what we do, the changes need to be committed to the repo prior
to tagging. If this were implemented today and we released v2.3.4, then a
year from today if someone rebuilds v2.3.4 from the tag, using whatever
build process we have in place (today that's Grunt), then the copyright on
the generated build should be 2013, not 2014.

As for Copyright \d{4} replacements, that could potentially work, but
this whole process needs to happen on its own, as one of the first things
that happens during the year. This is a much bigger problem than just
keeping this specific repo updated every year.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1384#issuecomment-28228601
.

[mgol]

@scottgonzalez Preserving the original year for a commit is a valid point, we do generate current date on each build no matter when the commit was created, though. Perhaps the build task should be modified to use the commit date, not the current one. The same could potentially be done for year substitutions - your case would be served, then.

[gibson042]

+1 @mzgol. I really like the idea of using commit timestamp instead of the system clock.

[mgol]

@ameyms Do you want to try to make the time rely on commit date instead of current one or should we do it by ourselves?

[ameyms]

I would love to, but I don't have access to my computer till 18th.
If this can wait 5 days, I'll push this on Monday.

Amey
On Nov 12, 2013 10:09 PM, "Michał Gołębiowski" notifications@github.com
wrote:

@ameyms https://github.com/ameyms Do you want to try to make the time
rely on commit date instead of current one or should we do it by ourselves?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1384#issuecomment-28309533
.

[dmethvin]

Sure that's fine @ameyms, it's not critical.

[ameyms]

Alright. Will do it on Monday then.
Thanks!

Amey
On Nov 12, 2013 11:01 PM, "Dave Methvin" notifications@github.com wrote:

Sure that's fine @ameyms https://github.com/ameyms, it's not critical.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1384#issuecomment-28314462
.

[dmethvin]

@ameyms last call for the beta!

[ghost]

Ami Szerzői \ d {4} pótlások, hogy esetleg dolgozni, de ez az egész folyamat kell, hogy megtörténjen a saját, mint az egyik első dolog, ami történik az év során. Ez egy sokkal nagyobb probléma, mint tartani a konkrét repo frissítik minden -- Fog tenni, hogy hétfőn majd. Köszönjük!de nem férnek hozzá a számítógép-ig 18-án. Ha ez vár 5 nap, én nyomja meg ezt hétfőn. Amey---,

[dmethvin]

I can reopen this if someone is willing to finish it.