year range

[jonschlinkert]

@tunnckoCore, remember the comment you made about copyright year ranges? I can't remember where that was, but I have an idea for how to improve the logic for determining copyright dates.

As a reminder of what I'm referring to... when the license for project X has something like the following:

Copyright (c) 2014 Jon Schlinkert

It will currently be updated to:

Copyright (c) 2014, 2017 Jon Schlinkert

Technically, this is correct, since you are only supposed to list years in which modifications were made, and update-copyright doesn't know whether or not I worked on project X during any other years that aren't mentioned in the license.

Solution

What if we add an option to fill in additional years? Then, in the update updater, we can actually parse the years from the git history and provide those on the options...

Thoughts?

[tunnckoCore]

Side note: sadly even don't use update et al.

Don't know. I don't understand copyrights fully. I understand that if it is a range you hold the license for exactly that range of years, no matter modifications are made or not. I believe there should be a difference between 2014-2017 and 2014, 2017 - in the first case is that you hold the license for all the years in range, in the second case you hold only for 2014 and 2017, that's how i understand it.

Don't know, maybe if you can share some links to learn more. :) In anyway i just started to not putting a year in the file banners - don't know if this is a good thing or not. The only places where some years is set is in the readme, by verb.

[jonschlinkert]

In anyway i just started to not putting a year in the file banners - don't know if this is a good thing or not.

Idk, I just want to be as compliant as possible so that companies and users who are required to follow rigid guidelines will be able to use our code without any worries.

[doowb]

What if we add an option to fill in additional years? Then, in the update updater, we can actually parse the years from the git history and provide those on the options...

I think this is a good idea.

[jonschlinkert]

k thx for the feedback @doowb and @tunnckoCore!

[jonschlinkert]

sadly even don't use update et al.

btw, I'm going to be pushing up changes that make update easier to override and customize. maybe that will help.

Even though you're not using update, I could use your feedback. Should we use ~/.update/ as the default directory for storing custom, user-defined config values for update (as well as any updaters)?

[tunnckoCore]

Maybe yea. It would be good, I like hidden dirs :D

btw, I'm going to be pushing up changes that make update easier to override and customize. maybe that will help.

As about that... I just don't have the time to make updaters for me and my cases/templates.